Firebird Trigger und CONSTRAINT

[hanspeter]

Hallo,

ich versuche gerade eine alte Interbase Datenbank nach Firebird zu migrieren.

Backup unter IB und Restore unter FB klappt (manchmal) bringt aber unreproduzierbare Fehler.
(Unterschiedliche Gbak sind verwendet.) Die Datenbank muss anschließend ziemlich aufwendig angepasst werden.
So z.B. mit gfix von SQL 1 auf SQL 3 u.s.w.

Ich versuche jetzt die Datenbank neu anzulegen und dann Tabelle für Tabelle zu übertragen.
Das funktioniert erst mal nicht, da Trigger und Constraints das Füllen einzelner Tabellen nicht zulassen.
Ich habe jetzt versucht, die Datenbank in 2 Phasen zu erzeugen.
1. Nur Tables anlegen und importieren.
2. Index,Trigger , Storedprocedure und Constraints definieren.

Teil 1 geht, bei Teil 2 bekomme ich Fehler.
Da ich die Datenbank komplett aus den Metadaten erzeugen kann, nicht aber phasenweise, gibt es eine Möglichkeit Triger und Constraints temporär abzuschalten?

Für einen Tip dankbar.

Gruß
Peter

[Morphie]

ALTER TRIGGER trigger_name INACTIVE;
ALTER TRIGGER trigger_name ACTIVE;

Constraints können nicht deaktiviert werden.

Aber eigentlich müsstest du doch (wie schon geschrieben) die Struktur und die Daten importieren können und anschließend die Trigger, Constraints usw. setzen können. Dabei musst du ggf. die logische Reihenfolge beachten. Aber eigentlich sollte das doch gehen :gruebel:

[hanspeter]

Jetzt bin ich etwas weiter.
Es scheint das FB die Datenprüfung genauer als der alte IB-Server nimmt.
Hier mal die Fehlermeldung.

violation of FOREIGN KEY constraint "".
violation of FOREIGN KEY constraint "KF_KS" on table "KEY_FUNKTION".
Foreign key reference target does not exist.
************************************************** *****************************/
ALTER TABLE KEY_FUNKTION ADD CONSTRAINT KF_KS FOREIGN KEY (KSNR) REFERENCES KEYSYSTEM (KSNR) ON DELETE CASCADE ON UPDATE CASCADE;

So richtig sehe ich die Fehlerursache noch nicht.

Hat wer noch einen Tip?

Gruß Peter

[Morphie]

Kannst du bis hierhin die mal bereits angelegte Struktur der betroffenen Tabellen posten? Inkl. Constaints, Indizies usw....

[hanspeter]

Zitat:

Zitat von Morphie (Beitrag 1197462)

Kannst du bis hierhin die mal bereits angelegte Struktur der betroffenen Tabellen posten? Inkl. Constaints, Indizies usw....

Leider nicht. (Geheimhaltungsbestimmung des Auftraggebers)
Ich denke aber das es sich um importierte Fehler aus IB handelt.

[Lemmy]

Zitat:

Zitat von hanspeter (Beitrag 1197467)

Leider nicht. (Geheimhaltungsbestimmung des Auftraggebers)
Ich denke aber das es sich um importierte Fehler aus IB handelt.

würde ich auch vermuten. Also die Daten per SQL abfragen und nach DB-Leichen suchen. Anders kommst Du da nicht zurande..

Die Metadatenanpassung von Firebird 2.1 hast Du auch gemacht (<Install>\Firebird_2_1\misc\upgrade\metadata)?

GRüße

[hanspeter]

Zitat:

Zitat von Lemmy (Beitrag 1197468)

würde ich auch vermuten. Also die Daten per SQL abfragen und nach DB-Leichen suchen. Anders kommst Du da nicht zurande..

Die Metadatenanpassung von Firebird 2.1 hast Du auch gemacht (<Install>\Firebird_2_1\misc\upgrade\metadata)?

GRüße

Nein.
Ich habe die Metadaten mit IBExpert in Interbase ausgegeben. (Der IB Server läuft auf meinem 64 bit OS nicht mehr als Dienst und muss manuell gestartet werden.)
Den Script habe ich fehlerbereinigt. Ohne Daten funktioniert das Anlegen einer leeren Datenbank.

Dann habe ich diesen Script geteilt in Domain/Tabellen und den ganzen Rest.
Ich erzeuge über IBDAC eine leere Datenbank.
Diese fülle ich nur über SQL Anweisungen. Dazu habe ich mir ein Tool gebaut, welches aus einem Select * From ... eine parameterisierte Insert Anweisung generiert und die
Parameter aus der Selektion füllt.
Realisiert mit IBDAC. Da der Fehler nur bei einigen Constaints auftritt, wird es wohl an den Daten liegen.
Das Problem ist halt, das ich eine grundsätzliche Lösung finden muss, da das Teil als Migrationstool beim Anwender laufen muss.


Grüße

[Lemmy]

ah klar - dann musst da da nichts machen. Aber das mit dem automatischen Tool wird schwer - außer du prüfst vor der ersten Datenübernahme die ganzen Constraints manuell per SQL ab und korrigierst die noch in der "alten" Version

[hanspeter]

Mal eine dumme Frage.

Die Anweisung

ALTER TABLE AKTIVTARGET ADD CONSTRAINT FK_AKTIVI_AV FOREIGN KEY (PLANNR, PERSNR) REFERENCES AKT_PERSID (PLANNR, LFDNR)

bedeutet doch das das Schlüsselpaar PLANNR, PERSNR in AKTIVTARGET eine Referenz auf PLANNR, LFDNR in AKT_PERSID haben muss.

Referenz von PERSNR auf LFDNR sieht mir wie Unsinn = Altlast aus die FB nicht mehr schluckt oder mache ich hier einen Denkfehler.

Gruß

[mjustin]

IBExpert enthält eine Funktion für den Export der gesamten Datenbank (Metadaten und Daten) als SQL-Skriptdatei, die im Prinzip so aufgebaut ist dass RI / Constraints keine Probleme verursachen sollten.

Wenn ich mich richtig erinnere war es ein externes Kommandozeilenprogramm, aber es ist schon ein paar Jahre her dass ich es benutzt habe.