Violation of FOREIGN KEY

[Jürgen Malzkorn]

Ich verwende eine TIBSQL-Komponente für den folgenden Befehl: "alter table xyz add constraint FK_NAME foreign key (Feldname) references Tabelle(Feldname) on update cascade on delete cascade". Dieser Befehl wird für verschiedene Interbase-Tabellen ausgeführt. Bei einigen klappt´s, bei anderen erhalte ich permanent die Fehlermeldung: "violation of FOREIGN KEY constraint "PK_Primaerindex" on table "Mastertabelle". Die erforderlichen Primärindices sind erstellt. Das Detailfeld hat denselben Datentyp. Die zum Detailfeld enthaltenen Daten in der Detailtabelle sind mit den Daten in der Mastertabelle identisch, also die Schlüsselwerte stimmen. Trotzdem erhalte ich diese Fehlermeldung. Wo muß ich suchen, um diesen Fehler zu beheben?

[Torsten Grundke]

Hallo Jürgen,

ich würde eine neue Datenbank mit den entsprechenden foreign key's anlegen und danach alle Daten aus der Original-DB in die neue DB übertragen.

Tschüß

Torste

[Andreas Kosch]

Hallo,

was passiert, wenn die Datenbank über BACKUP gesichert, gelöscht und danach über RESTORE wiederhergestellt wird? Tritt dann das Problem immer noch auf, obwohl in den beteiligten Tabellen über SELECT kein Verstoss gegen die CONSTRAINT-Regel ersichtlich ist

[Jürgen Malzkorn]

Hallo Torsten, hallo Herr Kosch,

Der Versuch mit Backup und Restore war das 1. was ich gemacht habe. Doch mit gleichem Ergebnis. Zu Torsten: Die Datenbank wird quasi neu angelegt und zwar aus der vorhandenen heraus. Zur Erklärung: Wegen ständiger Erweiterung der DB bedingt durch Kundenwünsche, haben wir eine Art DataPump entwickelt, der die Aufgabe hat, die vorhandenen Kundendaten beim Kunden in die erweiterte, neue Version der DB zu überspielen. Zuvor wird mit Marathon durch Metadata-Extract ein SQL-Script erstellt. Nach Ablauf des Scripts steht die so neu erstellte Version der DB ohne Datensätze zur Verfügung. Der DataPump öffnet nun die Vorgänger-Version und ermittelt über die Systemtabellen in der Nachfolgerversion alle nötigen Angaben der Foreign-Keys. Diese Angaben werden in eine ClientDataSet zwischengespeichert, da nun alle FOREIGN KEYS gelöscht werden müssen, weil sonst die Datensatzübertragung fehlschlägt. Nach Übertragung der Datensätze öffnet der DataPump die ClientDataSet und bildet aus den dort gespeicherten FOREIGN-KEY-Angaben den SQL-Konstrukt "alter table ZielTab add constraint...." und führt diese Anweisung direkt aus. Bei einigen Tabellen funktioniert das Hinzufügen, jedoch bei 2 Tabellen kommt die oben beschriebene Fehlermeldung. Eigenartig ist folgendes: Versuche ich über Marathon in der neuen DB von Hand den Foreign Key einzugeben, kommt es zur selben Fehlermeldung. Öffne ich jedoch die Arbeitsdatenbank, die bis auf die Testdatensätze nichts anderes ist als die Zieldatenbank, läßt sich der besagte Foreign-Key ohne Weiteres anlegen oder auch löschen. Auch der Versuch über IBConsole eine Metadata-Sicherung zu erstellen und anschließend zu restoren, liefert beim Bearbeiten durch den DataPump diese Fehlermeldung. Wie gesagt, die Masterkey-Werte sind in den Detailtabellen alle vorhanden. Eine Neuerstellung der gesamten DB von Hand ist völlig undenkbar. Zuviele Tabellen, Generatoren, Trigger und zuviele Stored-Procedures, die in Dependencies zueinander stehen. Ich bin ehrlich gesagt, vollkommen ratlos

[Jürgen Malzkorn]

Hallo Herr Kosch,
noch ein Nachtrag zu meiner Antwort vom 07/11 10.25 Uhr. Wenn ich im Sourcecode des DataPump die Stelle auskommentiere, wo die Datensätze pro Tabelle in einer Schleife übertragen werden, also nur das Löschen und wieder Hinzufügen der Foreign-Keys zulasse, läuft die ganze Sache fehlerfrei ab. Aber an den Daten kann es für die betroffenen Tabellen nicht liegen. In den Detailtabellen werden ausschließlich nur die erlaubten Schlüsselwerte verwendet

[Andreas Kosch]

Hallo,

was passiert, wenn zwischen dem Übertragen der Datensätze in die Tabellen und der Änderung am Datenbank-Schema (ALTER ...) die Transaktion/Datenbankverbindung explizit getrennt und neu aufgebaut wird

[Torsten Grundke]

Hallo Jürgen,

ich habe die Erfahrung gemacht, dass das nachträgliche Einfügen von Foreign-Key's in der Regel nur bei "leeren" DB funktioniert. Sobald Daten in den betroffenen Tabellen sind kann es zu dem genannten Fehler kommen, auch wenn die Datenkonsistenz gegeben ist. Deshalb lege ich bei nachträglichen Hinzufügen von foreign-Key's immer eine neue DB an und erstelle die entsprechenden FK. Erst danach werden die Daten in die neue DB übertragen.

Solange die Datenkonsistenz gegeben ist muß dieser Weg funktionieren. Allerdings müssen die einzelnen Tabellen in der richtigen Reihenfolge mit Daten gefüllt werden (zuerst die Master-Tabellen). Dazu ist eine Analyse (programmgesteuert) der Datenabhängigkeiten über die Systemtabellen notwendig.

Tschüß

Torste

[Jürgen Malzkorn]

Hallo Herr Kosch,

mache ich bereits, weil ich in früheren Zeiten schon festgestellt habe, daß der Interbase "ALTER..." nicht akzeptiert, wenn man vorher nicht die Transactions und die DB-Connection geschlossen und vor Ausführung von "ALTER..." wieder in Gang gesetzt hat. Es ändert sich nichts an der Fehlermeldung

[Jürgen Malzkorn]

Hallo Thorsten,

danke für Deinen Ratschlag. Über diese Möglichkeit habe ich auch schon nachgedacht. Es wäre halt nur schade, wenn ich darauf zurückgreifen müsste, da der DataPump dann gänzlich umgestellt werden müsste und dies wieder zusätzliche Zeit kostet und das verstehen unsere Kunden im Moment überhaupt nicht. Trotzdem, vielen Dank.

Gruss Jürge