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.

[IBExpert]

war vor ganz langer zeit mal ein externes programm, ist aber seit jahren im Menü oder per ibeblock script machbar
http://ibexpert.net/ibe/index.php?n=Doc.ExtractMetadata
http://ibexpert.net/ibe/index.php?n=...xtractMetadata

Wir haben im Moment regelmäßig bei Kundenprojekten mit Migrationen von Interbase nach Firebird zu tun, da nutzen
wir auch immer diesen Weg. Bei Interbase scheinen sich gewisse Stabilitätsprobleme zu zeigen, die auch durch
neue Versionen nicht behoben sind. Die Portierung auf Firebird ging oft einfacher als man denkt und hat bisher
immer die Stabilitätsprobleme behoben und ganz nebenbei auch noch erhebliche Geschwindigkeitsvorteile gebracht.

Wenn du also mit IBExpert einen Dump der DB als Script gemacht hast (geht mit Blobs aber nur in der Vollversion),
dann kannst du das jederzeit in jede andere Version von Interbase oder Firebird wieder einspielen. Mit ganz wenig
Aufwand lässt dabei zum Beispiel auch ein Teil der Daten ausschliessen oder vor dem einspielen Objektnamen per
searchandreplace verändern, falls man die doch mal zu lang benannt hat oder Schlüsselworte der Zielplattform
benutzt hat.

Um fehlerhafte Records zu finden kann man daher einfach die eigene Datenbank mit tools-extract metadata in ein
Script exportieren (auf den Seiten Metadata und Data alle Tabellen auswählen, auf den Options dann noch
die passenden Optionen anwählen, auf jeden Fall aber Extract Blobs sofern diese auch exportiert werden sollen.
Ganz oben in der Toolbar gibt es noch eine Option, wie das Script aufgebaut sein soll, ich nutze immer
"seperate files", bei der ein Pfad angegeben werden muss ).

Danach dann einfach in IBExpert im SQL Executive die Datei ibe$start.sql aus dem o.a. Pfad öffnen, die
create database anweisung so manipulieren, das diese nun auf die Ziel Plattform zeigt (also anderer Port,
andere Client DLL und/oder anderer Servername etc. )

Dann einfach mit F9 ausführen und warten ...

Wenn Fehler auftreten, dann seht Ihr die unten im Fehlerprotokoll, in dem Ihr mit rechte Maustaste alle Statements
in die Zwischenablage packen könnt, die probleme machen. Der effektivste Weg ist dabei, dann diese fehlerhaften
Daten in der Quelldb zu manipulieren, d.h. einfach löschen wenn möglich oder Foreign Keys zum Beispiel für
die Migration bereinigen. Meistens sind da bei Interbase Daten drin, die per Defintion zwar nicht drin sein
dürften, aber für die Migration muß das nun mal bereinigt werden. Die findet man meist aber mit so was wie
... select ... where not exists ...

Das IBExpert Extractmetadata Script erzeugt die Metadaten in zwei Schritten
-zuerst Create Table, generator, Prozeduren mit empty body usw
-Daten einspielen per insert
-am ende dann erzeugen der trigger, prozeduren mit Quelltext compilieren, Primary Keys, Foreign keys, indizes usw

Das Verfahren ist mti hunderten Datenbanken bei Kunden getestet und kann auch reproduzierbar gescriptet werden,
um das ganze auch mit bei Kunden installierten Datenbanken unattended zu machen, dafür gibt es weiterhin
eine Kommandozeileversion und eine DLL, die mit entsprechender Lizenz weitergegeben werden kann.

Bei sehr großen Datenbanken kann das Verfahren durchaus 3 bis 5 mal so lang dauern wie ein Backup/Restore,
bietet aber ganz andere Möglichkeiten, unter anderem die gleichzeitige Migration der Datenbank auf dialekt 3,
die Migration auf andere Charsets, auch auf UTF8, den Ownerwechsel ohne Systemtabellentricksereien, globale
Objektumbenennung usw.

Wir hatten Ende 2012 wieder ein Kundenprojekt, wo der Kunde mehrere hunderte Kundeninstallation umstellen musste,
das war nach einem Workshop und diversen hausinternen Tests beim Kunden problemlos durchgelaufen.

Solche Workshops machen aber meistens nur kundenspezifisch Sinn, da jeder Kunde nur die Sachen braucht, die
in seiner DB Ärger machen. Das kann man aber jederzeit selbst ausprobieren oder halt bei uns buchen


Gruß
Holger

[hanspeter]

Danke für die ausführliche Anleitung.

Ich habe es inzwischen hinbekommen.

Ich weis nicht warum aber die Methode erst Datenbank erzeugen ohne Constraints und Trigger, dann die Daten übernehmen, dann Trigger und Constraints hat nicht funktioniert.
Aus irgendeinen Grund gab es dann beim Erzeugen der FOREIGN KEY jede Menge Fehler.
Ein Backup/Restore war auch nicht ohne weiteres möglich. Die aus IB übernommenen Metadaten sind nicht fehlerfrei.
(z.B. gleiche Feldnamen in unterschiedlichen Tabellen nicht mit der Tabelle spezifiziert, Schlüsselwörter als Feldname...)
Die Umstellung von SQL Dialekt 1 auf 3 brachte auch ein paar Probleme.

Ich habe das Problem jetzt so gelöst:

1. Ich erzeuge aus einem Script alle Datenbankobjekte außer den Triggern.
Also auch Constraint bzw. FOREIGN KEY.

2. Der Import erfolgt über IBDAC tabellenweise.
3. Die zu importierenden Tabellen habe ich in einer String-Array Konstante abgelegt und diese entsprechend der Constraints sortiert.
4. Die eine oder andere Fehlermeldung konnte ich durch Änderung der Tabellen Sortierreihenfolge beseitigen.

5. Da ich satzweise Kopiere kann ich fehlerhafte Sätze erkennen und auslassen.

Jetzt gelingt es mir die Datenbank von IB nach FB fehlerfrei zu kopieren.


Gruß
Peter