Firebird Versionswechsel

[hanspeter]

Hallo,
kennt wer ein (Kauf) Tool mit welchen ich eine Firebird Datenbank in einem ASCII Format (CSV,XML oder ähnlich)
ausgeben und einlesen kann?

Ich archiviere Firebird Datenbanken, welche mit unterschiedlichen Versionen erzeugt wurden.
Gelegentlich wird die eine oder andere Datenbank nochmals benötigt.

Standardvorgehensweise ist ja Backup mit der Erzeugerversion und Restore in der neuen Version.
Auf meiner Entwicklungsmaschine habe ich jeweils die neuste Version des Servers als Dienst und alle anderen unter einer anderen Portadresse als Application laufen.
Diese Vorgehensweise ist aber für den Nutzer des Programms nicht akzeptabel.

Wenn so ein Tool nicht beschaffbar ist, denke ich dieses mit embedded Firebird selbst zu schreiben, möchte mir diese
Arbeit aber gerne sparen.

Der Ablauf:

Erkenne Version der vorliegenden Datenbank.
Gib die Daten über embeddedSQL als Transferdatei aus.
Lese die Daten in der aktuellen FB Version ein.
Da in FB2.1 einige nicht als reserviert gekennzeichnete Wörter (z.B. Start oder Starts) nicht als Tabellenname funktionieren, muss ich beim Einlesen den Tabellennamen anpassen.
Für einen Tip dankbar.

Gruß Peter

[mkinzler]

Man könnte auch ein SQL-Skript erzeugen. Dieses liese sich dan, wenn nicht Features neuerer Versionen benötigt werden, auch in ältere Versionen einspielen.

[hanspeter]

Zitat von mkinzler:

Man könnte auch ein SQL-Skript erzeugen. Dieses liese sich dan, wenn nicht Features neuerer Versionen benötigt werden, auch in ältere Versionen einspielen.

So macht das der IBExpert.
Die zugehörige Dll ist als Kaufteil verfügbar.
Was ich für ein Zwischenformat nehme ist aber eigentlich egal.
Mich interessiert eigentlich nur ob es sowas schon fertig gibt.

Gibt es übrigens eine Möglichkeit ohne Server beir der *.fdb Datei die Version herauszubekommen?


Peter

[Hansa]

Warum verwendest du denn dann nicht IBExpert ? Es ist doch ein leichtes solche Sachen als eigenen Kommentar reinzuschreiben. Muss das automatisiert werden ?

Tja, dann eben so und das im Anhang ist zu sehen.

ShowMessage(DataModul.Database.Version);

[mkinzler]

Zitat:

Warum verwendest du denn dann nicht IBExpert ? Es ist doch ein leichtes solche Sachen als eigenen Kommentar reinzuschreiben. Muss das automatisiert werden ? Shocked

Dann müsste jeder Kunde ja IBExpert installiert haben.

[Hansa]

Dann soll er IBEScript verwenden. Sichere ich meine Quelltexte, dann zumindest auch noch die DB-Definition. Und zwar genau mit dem Teil. Dem ist auch egal, ob embedded oder nicht.

[hanspeter]

Zitat von Hansa:

Dann soll er IBEScript verwenden. Sichere ich meine Quelltexte, dann zumindest auch noch die DB-Definition. Und zwar genau mit dem Teil. Dem ist auch egal, ob embedded oder nicht.

1. Will ich beim Kunden kein IBExpert installieren.
2. Müßte ich dann die Bedienung erklären.
3. Müßte ich trotzdem die zur Datenbank gehörige Serverversion installieren.

Die Datenbank handelt eine Veranstaltung und geht danach in die Ablage.

Gelegentlich will jemand in den alten Daten mal was nachsehen. (Wieviele Starter waren in einer Prüfung vor drei Jahren)
Da sollte ein Datenbankimport schon automatisch laufen.

Mich interessiert ja auch nur ob es ein fertiges Tool gibt, welches evenduell auch an dem Server vorbei geht.
So wie es die Datenrettungstools für FB es auch machen.

Zum selber Programmieren habe ich zwei gangbare Ansätze. Das ist einmal über die IBExpert- IBScript dll.
Da ich als Zugriffsschicht IBDAC vrwende, biete sich hier eine Variante mit Memorytable und Zwischenspeicherung als
XML an.

Gruß
Peter

[KrasserChecker]

Schau mal hier:

SQL Manager for Interbase/FireBird

Da gibt es neben dem SQL Manager auch noch andere Produkte, die dir evt. weiterhelfen könnten.
Außerdem gibt es von dem SQL Manager auch noch eine "Lite"-Version, mit der man das Programm auch erstmal ohne es zu kaufen nutzen kann.

[Lemmy]

Hi,

Zitat von hanspeter:

Die Datenbank handelt eine Veranstaltung und geht danach in die Ablage.

du hast Dir dabei sicherlich einiges überlegt das Design so zu machen, vielleicht war es auch der Wunsch des Anwenders - aber dieses Vorgehen führt meiner Meinung nur zu Problemen:

Ich denke doch, dass die Leute nicht direkt in der Datenbank rumeditieren, sondern dass Du eine Anwendung dazu hast. Was passiert, wenn Du diese mal änderst und die Anwendung eine andere Tabellenstruktur erwartet? Vielleicht kommen ja neue Tabellen dazu usw...

Ein "Reimport" über Backup-Restore scheidet daher meiner Meinung nach aus, da Du sonst die Datenbank nach dem Öffnen erst mal überprüfen musst und gegebenenfalls die Tabellenstruktur anpassen musst.

Ein Export in ein anderes Format wie XML ist meiner Meinung nach aber auch unsinnig, denn dazu hast Du ja eigentlich die Firebird-DB im Einsatz.

Was spricht dagegen in einer Datenbank mehrere Veranstaltungen zu speichern? Der Anwender muss davon ja nichts mitbekommen. Vor allem muss er nicht alle paar Monate die Datenbank runterfahren, das Datenbankfile wegkopieren und ein neues anlegen...

Sollte das aber aus welchen Gründen auch immer nicht gehen, dann sehe ich den Export in ein neutrales Format wie XML als "beste unsinnige" Lösung an Da kannst Du dann beim Importieren evtl. Änderungen im Datenmodell einfach handhaben. Für den Export in ein XML sollte es eigentlich fertige Komponenten geben. Im schlimmsten Fall jede Tabelle einzeln in je ein XMl auslesen und alle XML in einen Zip-Container verfrachten.

Wenn Du dir das Leben dann noch vereinfachen willst, baust Du dir einen kleinen Viewer, der den Ihnalt der ausgelesenen XML-Files anzeigen kann, dann müssen die Anwender die Daten nicht mehr importieren....

GRüße
Lemmy

[hanspeter]

Zitat von Lemmy:

du hast Dir dabei sicherlich einiges überlegt das Design so zu machen, vielleicht war es auch der Wunsch des Anwenders - aber dieses Vorgehen führt meiner Meinung nur zu Problemen:

Doch das Design macht schon Sinn.
Die Datenbank wird vor einer Sportveranstaltung angelegt und wird nach dem Ende der Veranstaltung nicht mehr benötigt. Die Aufbewahrungsfrist beträgt max. 4 Wochen für Einsprüche abrufbar und dann 1 Jahr offline.
Alle relevanten Daten wie Teilnehmeradressen Zahlungen u.s.w. werden in eine Archivdatenbank übernommen und dort für zukünftige Veranstaltungen vorgehalten.
Die Ergebnisse werden in eine zentrale Ergebnisdatenbank übertragen.
Im Laufe der Jahre sind das etwa einhundert *.FDB Dateien geworden.

Die Datenbank selbst wird in der Vorbereitungsphase mehrfach per email übertragen, sollte deshalb schon nicht allzu groß sein.
In einem Ordner werden neben dieser Datenbank noch zusätzliche Informationen der Veranstaltung wie Programmheft, Werbevorlagen, Schriftverkehr
Jetzt kam mal ein User auf die Idee die Teilnehmerentwicklung der letzten 5 Jahre in einer bestimmten Prüfung zu wollen. Jede der Datenbanken, die nach Vereinen archiviert sind wurde mal für eine Minute benötigt. Dank der Versionen eine Heidenarbeit.
Das Zweischenformat benötige ich nur temporär. Datenbank unter 1.5 ausgeben, unter 2.1 einlesen - Temporäre Dateien löschen.
Über ein lesbares Zwischenformat muss ich ohnehin gehen, da einige Feldbezeichner und ein Tabellenname geändert sind. (FB2.1 läßt keine Tabellen mit dem Namen Start,Starts und
ähnliche Ableitungen zu.)
Alternativ könnte man auch überlegen, die Funktionalität von IBExpert zu nutzen und die Datenbank nicht als FDB Datei, sondern als Metadatenausgabe zu archvieren.
Hier sollte es wohl reichen eine Lizenz von IBScript zu kaufen?

Gruß Peter