Firebird Trigger und CONSTRAINT

[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