Firebird: Dump eines einzelnen Datensatzes

[Opa Knack]

Hallo,

leider hat mich die Suche nicht unbedingt weitergebracht, deshalb nun hier die Frage:

Ich verwalte Bewerberdaten über eine lokale Firebird-DB. Um diese Daten schnell weitergeben zu können, müsste ich nun einzelne Records "exportieren" können. Grundgedanke dahinter ist, dass der entsprechende Datensatz dadurch, dass die Daten ja schon in der Form bestehen, die ich zur Weiterverarbeitung brauche, "zusammengepackt" werden sollen und per E-Mail nach entsprechendem Import direkt weiterverwendet werden können.

Mein erster Ansatz, nachdem ich keine praktikable Lösung gefunden habe, war, dass ich die Daten in eine INI-Datei exportiert habe, welche dann nach Weitergabe genutzt werden könnte. Mein Problem dabei ist, dass neben den reinen Textinhalten auch weitere Daten wie z. B. Zeugnisse und Fotos enthalten sind, die ich über die INI-Lösung schlecht handeln kann (mal abgesehen davon, dass eine 3MB-INI-Daten evtl. auch noch andere Probleme erzeugen würde).

Die Frage lautet nun also: Wie kann ich einen einzelnen Datensatz aus eine Firebird-DB exportieren und in eine andere importieren (wobei es dann noch den Zusatzpunkt gäbe, dass einige Daten [z. B. Historie, ID, ...] nicht exportiert werden sollen und erst beim Import eingesetzt werden)?

Ich bin für jeden Tipp dankbar.

Viele Grüße
Opa

[mkinzler]

Man könnte es z.B. als XML-Datei exportieren oder als SQL-(Insert)-Skript

[blackfin]

Warum in die Ferne schweifen, wenn eine Firebird-Datenbank doch auch nichts anderes ist als eine Datei?

Erstelle doch beim Export einfach per Script eine zweite lokale Datenbank als "Austausch-Format" und kopiere den Datensatz bzw. den relevanten Teil davon in die kleine, neu erstellte Datenbank rüber. (SELECT von Datenbank 1 => Cursor => INSERT in Datenbank 2)
Diese Mini-Datenbank dann noch optional vom Programm packen / zippen lassen und fertig ist dein kompatibles Austausch-Format.
Auf der Gegenseite machst du das Ganze umgekehrt

Wenn du binäre Daten in der Datenbank hast, könntest du die Blob-Streams auch gleich vor dem INSERT packen (z.B. mit BZIP2 geht das wunderbar), dann brauchst du die Datenbank selbst nicht mehr zippen (obwohl das sicher besser ist, da sich die Datenbank-Struktur meist auch noch recht gut packen lässt).

[IBExpert]

Zitat von blackfin:

Warum in die Ferne schweifen, wenn eine Firebird-Datenbank doch auch nichts anderes ist als eine Datei?

Erstelle doch beim Export einfach per Script eine zweite lokale Datenbank als "Austausch-Format" und kopiere den Datensatz bzw. den relevanten Teil davon in die kleine, neu erstellte Datenbank rüber. (SELECT von Datenbank 1 => Cursor => INSERT in Datenbank 2)
Diese Mini-Datenbank dann noch optional vom Programm packen / zippen lassen und fertig ist dein kompatibles Austausch-Format.
Auf der Gegenseite machst du das Ganze umgekehrt

Wenn du binäre Daten in der Datenbank hast, könntest du die Blob-Streams auch gleich vor dem INSERT packen (z.B. mit BZIP2 geht das wunderbar), dann brauchst du die Datenbank selbst nicht mehr zippen (obwohl das sicher besser ist, da sich die Datenbank-Struktur meist auch noch recht gut packen lässt).

Idee ist eigentlich ganz gut, aber der overhead ist immens, weil du in der Datenbank immer alle Metadaten und Systemtabellen schon drin hast. Daher ist eine leere Firebird DB auch ohne jede eigene Tabelle je nach Pagesize 0,5-2 MB groß. Aus den Daten den realen Insert zu erzeugen, den du auf der Gegenseite wieder direkt nutzen kannst, ist aus meienr Sicht die flexibelste Version und hat sicherlich weniger Overheade als ytpische XML Strukturen, weil bei denen jeder Feldname Tag meist doppelt auftaucht. Die Behandlung von Blobs ist ein anderes Thema, aber vielelicht lässt du dich ja von dem Verfahren inspirieren, wie wir das in ibexpert auch mit blobs machen
http://www.ibexpert.net/ibe/index.ph...ve#SetBlobfile

Gruß
Holger
www.ibexpert.com

[blackfin]

Das stimmt schon mit dem grossen Overhead, aber eine (fast) leere FB-Datenbank dampft durch Zippen mächtig ein, was das ganze fürs Emailen ja dann doch mehr als tauglich macht, oder wo ist der Denkfehler?
Ich habe hier z.B. eine FB-Datenbank mit 100 Datensätzen mit jeweils 2 128x128 Bitmaps (+ einige andere Text oder Integer-Felder), in BLOB-Felder mit BZIP2 gepackt, diese Datei hat ca. 7MB, diese gesamt nochmal durchs ZIP geschmissen ca. 3MB, geht locker per Email...mhm...

Natürlich ist deine Lösung die bessere, es ging mir da eher um "schnell und unkompliziert"

[Opa Knack]

Hallo,

Danke für eure Antworten. Ich hatte ursprünglich gehofft, dass es so etwas wie einen realen Dump für einen einzelnen Record gibt, bei dem ich (wie bei MySQL) eine Textdatei erzeugen kann, die ich dann entsprechend weitergeben kann. Nun werde ich mich erst einmal mit der "Austauschdatenbank" beschäftigen und mal schauen, wie groß der Overhead nun letztlich werden wird.

Gruß
Opa

[Opa Knack]

Hallo nochmal,

nach ein paar Tests stellt sich mir nun folgende Frage:

Ich habe schon häufiger vom TClientDataSet gelesen, welches seine Daten ja auch binär abspeichern kann. Nun drängt sich mir natürlich der Gedanke auf, dass ich den zu exportierenden Datensatz einlesen und in ein TClientDataSet kopieren könnte, um dieses dann abzuspeichern.

Hat jemand von euch Erfahrungen damit gemacht? Funktioniert das so, wie ich mir das denke, oder habe ich irgendwo einen Denkfehler? Und sollte das so klappen: Hat jemand eine Idee, wie ich die Felderdefinitionen der bestehenden Datenbank im ClientDataSet erzeugen kann, ohne jedes einzelne manuell zu erstellen?

Danke und Gruß
Opa

[mkinzler]

Dann kannst du es gleich manuell in eine CSV oder XML Datei Packen

[Opa Knack]

Hallo,

das Problem dabei ist ja, dass auch diverse Blob-Felder mit mitunter größeren Einträgen (z. B. Arbeitszeugnisse, ...) enthalten sind. Ich habe gelesen, dass das für XML nicht unbedingt ratsam ist. Nebenbei besteht dabei ja auch das gleiche Problem: Wie bekomme ich die Daten in das entsprechende Format und wie kann ich sie wieder auswerten?

Danke und Gruß
Opa

[mkinzler]

TClientDataset verwendet aber eine XML-artige Struktur