violation of FOREIGN KEY constraint

[hoika]

Hallo,
Paradox, die gute alte Zeit

Also ich würde vom SQL die Finger weglassen.
Sowas wie

Delete From DetailTable Where DetailTable.MasterId not In (Select MasterTable.MasterId From MasterTable)
dauert unter Paradox i.d.R. sehr lange.

Wenn du eh an alle Tabellen ranmusst:
Select DetailId,MasterId From DetailTable -> rein in eine TStringList DetailList
Select MasterTable.MasterId From MasterTable -> rein in eine TStringList MasterList

und jetzt alle Details durchlaufen und nach der MasterId in der MasterList suchen,
wenn nicht vorhanden, den Detailsatz löschen.

[nahpets]

Was ich hier aus dem Quelltext nicht ganz so genau entnehmen kann:

Delphi-Quellcode:

            InsertSQL := Format('INSERT INTO "%s" (%s) VALUES (%s)', [TableName, InsertFieldNames, InsertFieldValues]);
            qry_FB.SQL.Add(InsertSQL);
...
                { Nun die Werte je nach Datentyp übertragen von der Quelle ins Ziel }
                case tbl_Pdx.Fields[k].DataType of
                  ftString :
                    qry_FB.ParamByName(FieldNameUpper).AsString := tbl_Pdx.FieldByName(FieldNameMixed).AsString;
                  ftSmallint,
                  ftInteger,
                  ftWord,
                  ftAutoInc :
                    qry_FB.ParamByName(FieldNameUpper).AsInteger := tbl_Pdx.FieldByName(FieldNameMixed).AsInteger;
...
                qry_FB.ExecSQL(InsertSQL);

Werden die Daten satzweise übernommen?

Wenn ja, Methode einfach, billig und unelegant:

Delphi-Quellcode:

Try
  qry_FB.ExecSQL(InsertSQL);
except
  on e : Exception do begin
    // ggfls. Fehlertyp abfragen und Fehlermeldung in 'ne Logdatei schreiben.
  end;
end;

Wie greifts Du auf die Datenbanken zu, noch über die BDE?

Wenn ja, dann schau Dir (soweit in Deinem Delphi vorhanden) bitte einmal die Komponente TBatchMove an.

Da kann man einiges Konfigurieren:

Quelle und Ziel.
Feldmapping.
Verhalten im Fehlerfalle.
Ausgabetabelle für die Datensätze mit Schlüsselverletzungen.

Eventuell etwas Literatur zu der Komponente:

http://docwiki.embarcadero.com/RADSt...wenden_-_Index
http://edn.embarcadero.com/article/25620
http://docs.embarcadero.com/products...epart_xml.html

Ach, was mir noch einfiel:

Wird die BDE benutzt, so kann man in der Localsql.hlp nachlesen, was mit SQL möglich ist. Dazu gehören auch die "handelsüblichen" Joins.

Die Hilfedatei liegt gewöhnlich im gleichen Verzeichnis, wie BDEAdmin.exe.

[Zwirbel]

Zitat von nahpets:

Was ich hier aus dem Quelltext nicht ganz so genau entnehmen kann:

Delphi-Quellcode:

            InsertSQL := Format('INSERT INTO "%s" (%s) VALUES (%s)', [TableName, InsertFieldNames, InsertFieldValues]);
            qry_FB.SQL.Add(InsertSQL);
...
                { Nun die Werte je nach Datentyp übertragen von der Quelle ins Ziel }
                case tbl_Pdx.Fields[k].DataType of
                  ftString :
                    qry_FB.ParamByName(FieldNameUpper).AsString := tbl_Pdx.FieldByName(FieldNameMixed).AsString;
                  ftSmallint,
                  ftInteger,
                  ftWord,
                  ftAutoInc :
                    qry_FB.ParamByName(FieldNameUpper).AsInteger := tbl_Pdx.FieldByName(FieldNameMixed).AsInteger;
...
                qry_FB.ExecSQL(InsertSQL);

Werden die Daten satzweise übernommen?

Wenn ja, Methode einfach, billig und unelegant:

Delphi-Quellcode:

Try
  qry_FB.ExecSQL(InsertSQL);
except
  on e : Exception do begin
    // ggfls. Fehlertyp abfragen und Fehlermeldung in 'ne Logdatei schreiben.
  end;
end;

Ja, die Daten werden datensatzweise übertragen. Genau so (Exception abfangen) habe ich es jetzt erst mal gemacht.

Zitat:

Wie greifts Du auf die Datenbanken zu, noch über die BDE?

Ja, habe mir diese alten BDE-Komponenten für Delphi Seattle geholt. Der Versuch über ODBC zuzugreifen und damit die BDE aus der Migrations-Applikation heraus zu halten scheitert daran, dass wir ausschließlich Paradox Tabellen im 7er Format einsetzen und das geht über ODBC nicht.

Wir haben uns jetzt dafür entschieden erst mal keine weitere Zeit in eine Optimierung zu investieren. Zum Glück haben wir von fast allen Kunden Echtdaten hier und haben so zumindest schon mal einen Überblick wo es überall haken kann und notfalls schalte ich diese derzeit zeitintensiven Reparaturroutinen per Option in der Migrations-Applikation ein.

Danke an alle für die vielfältigen und hilfreichen Informationen. Gruß, Markus

[jobo]

Zitat von Zwirbel:

..
Ja, habe mir diese alten BDE-Komponenten für Delphi Seattle geholt. Der Versuch über ODBC zuzugreifen und damit die BDE aus der Migrations-Applikation heraus zu halten scheitert daran, dass wir ausschließlich Paradox Tabellen im 7er Format einsetzen und das geht über ODBC nicht.

..

Was wollt Ihr damit bezwecken, die BDE da raus zu halten?
Es gibt nichts besseres als nativen Zugriff. Wem nützt der None-BDE Versuch, wenn die Einsatzbereiche eh alle BDE-"verseucht" sind? Ich würde es eher umgekehrt machen und eine entsprechend alte (alt genug), native Delphi Version nehmen. Das verspricht die wenigsten Fehlerquellen.
Eine Datenkopiermaschine sollte man auch mit alten Delphis noch gut hinbekommen oder?
(Nur mal so als Gedanke)

[nahpets]

Hierbei würd' ich sogar noch weiter gehen:

Nicht nur ein Delphi, dass noch die BDE mitbringt, sondern auch ein Windows, auf dem die BDE garantiert noch problemlos läuft.

Das war irgendwo vor Windows XP mit Delphi 7?

Wenn man daraus dann die entsprechenden Scripte für die Datenmigration erstellt, kann man diese Textdateien mit den Mitteln des neuen Systemes einlesen.

Bei Datenmigrationen hat bei mir die Sicherheit und Korrektheit der Daten immer Vorrang vor eventuell möglichen Optimierungen.

Wenn die Quelle also ein System mit BDE ist, dann wird die Migration mit der BDE gemacht, nichts kann besser unter Delphi mit Paradox umgehen, wie die BDE. Dann lasst sie doch einfach noch einmal zeigen, was in ihr steckt.

Und die weiter oben genannte Komponente TBatchCopy ist ja gerade für solche Aufgaben da. Über die BDE auf Paradox zugreifen und über die BDE auf alles was sie selbst kann bzw. über den Weg BDE-ODBC.

Fehlerbehandlung ist bei der Komponente inclusive.

[jobo]

Zitat von nahpets:

..
Nicht nur ein Delphi, dass noch die BDE mitbringt, sondern auch ein Windows, auf dem die BDE garantiert noch problemlos läuft.
..

Das dürfte sich vermutlich vor Ort beim Kunden von allein ergeben.

Zitat von nahpets:

..
Das war irgendwo vor Windows XP mit Delphi 7?
..

Ob man gleich so weit zurück muss?

Vielleicht sind ja geeignete Win 7 Installationen am Start oder ein Windows 2003 Server mit "Restgarantie". Irgendwie werden sie ja mit dem System noch arbeiten. Ein Vorrat an funktionierenden PC, die das klaglos und fehlerfrei machen, sollte also da sein. Sowas würde ich dann nehmen.

Wie auch immer, die Idee ist sicher klar geworden

[nahpets]

Sagen wir mal so: Unter XP hab' ich ab und an Fehler mit der BDE bekommen, die Konfiguration läuft nicht zwingend sauber.

Aber seien wir mal ehrlich:

Als wird per VM gemacht, warum dann da nicht mal eine mit 'nem älteren Windows aufsetzen?

Dann hat man ggfls. 'nen aktuellen und schnellen Rechner und trotzdem ein "altes" Windows. Und 'ne ältere Windows-CD wird man hoffentlich noch finden

Und wenn man nicht alle Kunden am gleichen Wochenende migriert, kann man sich ggfls. auch 'nen passenden Laptop für genau diesen Job fertig machen und von Kunde zu Kunde mitschleppen.

Ein ehemaliger Arbeitgeber hat noch 'ne Software mit Delphi 4, BDE und DBase-Dateien "am Laufen". Das sollte mal auf einen neueren Rechner. Mit Windows 7 war das aber nicht mehr stabil hinzubekommen. Also hat der neue Rechner ein "altes Windows" bekommen und läuft nun stabil.

An 'ne Datenmigration traut sich leider keiner ran.

[Zwirbel]

Zitat von jobo:

Zitat von Zwirbel:

..
Ja, habe mir diese alten BDE-Komponenten für Delphi Seattle geholt. Der Versuch über ODBC zuzugreifen und damit die BDE aus der Migrations-Applikation heraus zu halten scheitert daran, dass wir ausschließlich Paradox Tabellen im 7er Format einsetzen und das geht über ODBC nicht.

..

Was wollt Ihr damit bezwecken, die BDE da raus zu halten?

Das wollten wir nicht, es war nur ein Vorschlag in einem anderen Beitrag per ODBC, statt mit der BDE, auf die alten zu migrierenden Paradox-Daten zu zuzugreifen.

Zitat:

Es gibt nichts besseres als nativen Zugriff. Wem nützt der None-BDE Versuch, wenn die Einsatzbereiche eh alle BDE-"verseucht" sind? Ich würde es eher umgekehrt machen und eine entsprechend alte (alt genug), native Delphi Version nehmen. Das verspricht die wenigsten Fehlerquellen.
Eine Datenkopiermaschine sollte man auch mit alten Delphis noch gut hinbekommen oder?

Kommt auf das Alter des alten Delphis an. Das stammt aus dem letzten Jahrtausend, mehr sage ich nicht. Da wüsste ich jetzt nicht, wie ich bequem mit dem ollen Delphi Daten in eine FB-Datenbank schaufel. So wie im Moment scheint mir das ganz pragmatisch, neues Delphi mit aktuellen Schnittstellen zur neuen Ziel-Datenbank und als Zugriff in die alte Datenwelt noch die nativen BDE-Komponenten. Das scheint mir der beste Kompromiss zu sein.

[jobo]

Zitat von Zwirbel:

Kommt auf das Alter des alten Delphis an. Das stammt aus dem letzten Jahrtausend, mehr sage ich nicht. Da wüsste ich jetzt nicht, wie ich bequem mit dem ollen Delphi Daten in eine FB-Datenbank schaufel. So wie im Moment scheint mir das ganz pragmatisch, neues Delphi mit aktuellen Schnittstellen zur neuen Ziel-Datenbank und als Zugriff in die alte Datenwelt noch die nativen BDE-Komponenten. Das scheint mir der beste Kompromiss zu sein.

Ja, mit den BDE Komponenten ergibt es m.E. mehr Sinn. Wenn Ihr das so macht, ist meine Frage, warum ohne BDE ja auch eigentlich überflüssig.

Was nun das Alter der Delphiversion angeht, kann ich nur sagen, wir haben hier alte Anwendungen aus D5, die auch prima mit Oracle 12 arbeiten.

Exkurs
Und was bedeutet schon letztes Jahrtausend? Ich wohne in einem Haus aus dem letzten Jahrtausend, bis vor 2 Jahren fuhr ich ein Auto aus eben diesem Jahrtausend.
Ich habe Delphi immer geschätzt, weil es ein hohes Maß an Kontinuität in eine Welt brachte, in der MS das ganz anders handhabte.
Nur weil MS uns gelehrt hat, dass nichts so alt ist, wie die Software, die man dort gestern gekauft hat (oder geschenkt bekam), ist das bloße Alter einer Software für mich kein Kriterium.
Neu ist ja nicht per se besser, geschweige ausgereift und entbugged.
Aus der Perspektive würde ich reife Software gegenüber der neuen bevorzugen.

[mkinzler]

Ich würde mir überlegen ob es sinnvoll ist, nur zur Übernahme die BDE zu installieren.
Ich würde die Übernahme zudem in ei eigenes Hilfsprogramm auslagern.