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:

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 ? :shock:

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

Delphi-Quellcode:

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:

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:

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:

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

[mkinzler]

Zitat:

Hier sollte es wohl reichen eine Lizenz von IBScript zu kaufen?

Sollte afaik reichen

[Thomas Horstmann]

Hallo,

wir hatten bei unseren Anwendungen ein ähnlichen Problem und haben
dafür eine kleine Anwendung geschrieben.

Diese exportiert eine Interbase/Firebird Datenbank in eine Textdatei.
Zusätlich werden Blobs und Benutzerrechte in Referenzdateien gespeichert.

Die Import-Datenbank muss die gleiche Struktur haben wie beim Export. Wobei
hinzugekommene Objekte (Tabellen) kein Problem sind.

Um ggf. auch in alte Firebird Versionen importieren zu können (einige Kunden haben
noch so etwas), werden neuere Feldtypen wie z.B. Boolean nicht unterstützt.

Ich kann nicht garantieren, dass das ganze laufen wird. Aber die Anwendung ist Freeware
und kann getestet werden.

Download:
http://www.taurec.de/Download/taurec...c_Database.zip

Kurzinfo (auf unsere Anwendung zugeschnitten):
http://www.taurec.de/Dokumentation/t...e.html#Absturz

Vielleich hilft es :-)

Viele Grüsse
Tom

[Hansa]

Du bist echt unnötigerweise schwer am rumeiern. 8)

Zitat:

Zitat von hanspeter

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.

Das heißt im Klartext, die DB muss (sollte zumindest) 4 Wochen so bleiben, wie sie eben ist. Alte DBs sollen leicht wiederhergestellt werden können ?

Ne, ...Abbruch. Das da führt in keiner Weise weiter. Der Verein kriegt das sowieso nicht selber hin. Tip : garantiere den Zugriff wegen der möglichen Einsprüche auf die DB auf Limit 4 Wo., mit der Option diese Daten selber zu liefern und kassiere dafür. Archiviere von mir aus die DBs mit IBExtract/IBEBlock (IBEScript als Hinweis war eventuell faksch !) und wechsele nicht wegen Kleinigkeiten immer den FB-Server oder sogar die DB-Struktur. Außer Arbeit bringt das überhaupt nichts.

Also : DB als Metadata in Textdatei speichern und fertig. Notfalls noch diese Daten in Stringlist laden und die verwendete FB-Version da eintragen (siehe Eintrag #4).

[hanspeter]

Zitat:

Zitat von Thomas Horstmann

Hallo,

Ich kann nicht garantieren, dass das ganze laufen wird. Aber die Anwendung ist Freeware
und kann getestet werden.

Viele Grüsse
Tom

Vielen Dank für das Angebot.
Ich werde das mal ausprobieren.

Mit Gruß
Peter

[IBExpert]

Zitat:

Zitat von hanspeter

1. Will ich beim Kunden kein IBExpert installieren.
2. Müßte ich dann die Bedienung erklären.
...

wahrscheinlich ist dir IBEscript nicht bekannt, daher hier eine kurze Aufklärung
IBEscript ist ein eigenes Programm, benutzbar als kommandozeilen exe oder als dll
und Bestandteil der IBExpert Junior VAR Lizenz, mit der man das frei weitergeben
darf mit der eigenen Software. ibescript muss nicht installiert werden und hat
auch kein eigenes Benutzerinterface (mal von der Kommandozeilenversion abgesehen)

damit kannst du dann aus deinem Programm heraus jeden beliegen script Befehl von
ibexpert benutzen, zum beispiel ibec_extractmetadata

http://www.ibexpert.info/documentation/112607.html

wenn du selbst ein script erzeugen willst, das die db wieder vollständig herstellt,
dann ist das schon einiges an Aufwand, da muss einiges bei der Reihenfolge
berücksichtigt werden.

Gruß

Holger
www.ibexpert.com

[hanspeter]

Zitat:

Zitat von IBExpert

[

wahrscheinlich ist dir IBEscript nicht bekannt, daher hier eine kurze Aufklärung
Gruß

Holger
www.ibexpert.com

Doch die Funktionsweise ist mir bekannt.
Deswegen ja die Frage nach der Ibscript.Dll. Ich habe eine Einplatzlizenz für IBExpert. (Die Jahresendaktion)
Meine Frage war ja ob der Zukauf der o.g. dll für diese Aufgabe ausreicht.
Ibexpert möchte ich aus verschiedenen Gründen beim Anwender nicht von mir aus installieren.
Ich empfehle zwar auf Anfrage dieses Tool. Wer es braucht soll es sich aber selber kaufen.

Gruß Peter

[IBExpert]

Zitat:

Zitat von hanspeter

Deswegen ja die Frage nach der Ibscript.Dll. Ich habe eine Einplatzlizenz für IBExpert. (Die Jahresendaktion)
Meine Frage war ja ob der Zukauf der o.g. dll für diese Aufgabe ausreicht.

solange du in deinen datenbanken keine spezialitäten der alten oder neuen versionen benutzt hast kannst
du das ergebnisscript auf einer beliebigen firebird/interbase version wieder einspielen.
Mit der ibescript.dll geht sowohl das extrahieren als auch das wieder einspielen mit jeder
Zielplattform.

Gruß
Holger
www.ibexpert.com