violation of FOREIGN KEY constraint

[jobo]

Zitat:

Zitat von Zwirbel (Beitrag 1356660)

..
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:

Zitat von nahpets (Beitrag 1356747)

..
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:

Zitat von nahpets (Beitrag 1356747)

..
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:

Zitat von jobo (Beitrag 1356745)

Zitat:

Zitat von Zwirbel (Beitrag 1356660)

..
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. :-D 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.

[Zwirbel]

Zitat:

Zitat von nahpets (Beitrag 1356751)

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.

Die Option mit einem eigenen Rechner/Notebook zum Kunden aufzubrechen scheidet für uns definitiv aus. a) Sitzen die Kunden von Portugal, Spanien, Österreich, Schweiz, Deutschland auch, über Dänemark bis nach Russland und b) lässt mich keine IT-Abteilung mit einem fremden Rechner in deren Netz, die würden mich alle vorher erschießen. :-D Und ja, USB-Stick scheidet auch aus. :-D Alle Daten der Kunden müssen auf deren Equipment migriert werden. Und das muss möglichst alles voll automatisch laufen.

[nahpets]

Ok, ihr habt da schon etwas größere Baustellen.

Eigene Erfahrung:

Delphi 7 (aus dem Jahr 2002) und BDE funktioniert problemlos.

Delphi 7 und Oracle, MSSQL, PostGres, Ingres, MySQL, Firebird funktioniert problemlos.

Welches alte Delphi habt ihr? Über ODBC kann man eigentlich problemlos auch auf Firebird zugreifen, ist vielleicht etwas langsamer als über andere Wege, aber bisher hab' ich keine Probleme in der Form "Daten kommen nicht an, Daten kommen falsch an oder gar Zugriff nicht möglich." gehabt.

Und bei der Migration bitte den Weg über Scripte nicht auslassen.

Scripte kann man aus Delphi heraus per BDE-Zugriff auf Paradox erstellen.

ISQL kann man ggfls. auch aus dem Delphiprogramm heraus per ShellExecute ausführen.
Wenn man's mit Chromleiste will, kann man die Ausgabe von ISQL auch ins Programm übernehmen, so dass man hier das Delphiprogramm durchaus als alleiniges Migrations- und Steuerprogramm für die Datenübernahme gestalten kann.

Aber für genauere Tipps, Anregungen ... müsste man sich wohl doch etwas genauer in das Projekt und seine Bedingungen einarbeiten.

[jobo]

Zitat:

Zitat von Zwirbel (Beitrag 1356758)

Kommt auf das Alter des alten Delphis an. :-D 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.

[Jumpy]

Zitat:

Zitat von mkinzler (Beitrag 1356806)

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.

So wie ich das verstanden habe ist die BDE doch bei den Kunden noch im Einsatz und somit installiert. Das ist dann ja der Ort wo jeweils die Datenmigration stattfinden soll. Zumindest hab ich den TE so verstanden.
Allerdings würde ich auch empfehlen ein Extra-Tool dafür zu benutzen (oder Skripte oder so), da dies ja ein (pro Kunde) einmaliger Vorgang ist (hoffentlich).