violation of FOREIGN KEY constraint

[jobo]

Zitat von hoika:

mein SQL-Befehl von oben läuft ja.
Er ist halt nur langsam.

Welches SQL, das "Delete where not in"?

Diese Konstrukte sind in vielen DB nicht so dolle implementiert, erfahrungsgemäß, also gefühlt (ich habe natürlich noch nie eine solche Implementierung gesehen)
Viel versprechender ist es andersrum vorzugehen mittels eines Joins wie ihn DeddyH es hier
http://www.delphipraxis.net/1356311-post8.html
vorgeschlagen hat.

Es ist auch naheliegend, weil die Zeit nicht erst für Aufräumen "verschwendet" wird, sondern gleich die richtigen Daten selektiert werden. Also quasi "die guten ins Töpfchen, die schlechten .. " interessieren gar nicht.


Mal so nebenbei:
Ist Dir bekannt, dass die BDE heterogen arbeiten kann und Du sowas machen kannst*:

Code:

 insert into :firebirdtalias:desttable (f1,f2,f3)
SELECT
  Detail.*
FROM
  :bdetalias:Detail
  JOIN
    :bdetalias:Master ON Master.PK = Detail.FK

* Es sollte so gehen, ich hab hier nichts am Start, um das auszuprobieren.
Und es sollte halbwegs flott sein. Du brauchst natürlich einen BDE Alias auf die Zieldatenbank, vielleicht per ODBC, vlt. gibts auch einen nativen Treiber (Interbase?)


Grundsätzlich bei solchen Themen:
Je größer die Daten-Popelei** bei der Migration wird, desto eher gehe ich so vor.
Alle Altdaten werden in die Zieldatenbank übertragen, dort ist man idR flexibler (SQL) und schneller als mit dem veralteten Originalsystem.
Je nach Größe/Aufgabenstellung kann man das Verfahren dann abspecken / optimieren, natürlich vor allem dann, wenn es keine einmalige Sache ist, sondern auf mehreren Kundensystemen erfolgen soll.
Eine Variante des Vorgehens ist der vollständige Import der Altdaten in einen temporären Server mit identischer DB Installation. IdR kann man dann beim finalen Import im Zielsystem sehr bequem aus der Schwesterdb abfragen, also so halb heterogen.

** Popelei betrifft oft auch den Umbau von Feldinhalten. Dann spätestens sind wir beim Thema ETL (oder ELT), das geht wunderbar mit SQL und berechneten Feldern ohne meterlangen Programmcode. Dazu kann man auch schön Views nutzen, die die Transformation liefern. Kleine Fehler, die im Rahmen von Test auftauchen, sind schnell im View korrigiert ohne Programmcode zu ändern.
Natürlich gibt es auch super ETL tools, ist aber vielleicht für eine eigene Produktmigration nicht so der Knaller.