Hallo,

bei einem Programm-Update gibt es oft auch ein Update der Datenbank.
Welches ist der beste Weg eine Datenbank zu aktualisieren, wenn ein Programm-Update gemacht wird?

Mit Datenbank-Aktualisierung meine ich Tabellen, Felder, Trigger usw. in die Datenbank einzufügen oder zu ändern.

Mein Ansatz wäre:
1. Von der aktuellen Datenbank ein Backup machen
2. Datenbank mit neuer Struktur erstellen
3. Daten aus dem Backup in die neue Datenbank schreiben
4. Restore von der neuen Datenbank auf die aktuelle Datenbank machen,
fertig. Datenbank aktualisiert.

Ich bin mir nur nicht sicher, ob das der Beste und einfachste Weg ist.

Delphi 2010
Firebird 2.5
DBExpress
InnoSetup

1. Für das Backup ist der Anwender verantwortlich. Du kannst ihn vor dem Update aber gerne darauf hinweisen, dass ein Backup zu empfehlen ist und du keinerlei Ansprüche gegen dich akzeptierst, wenn er das nicht macht und durch das Update dann Probleme auftauchen.
Natürlich kannst du das Backup auch programmgesteuert machen. Aber wenn der Anwender große Datenmengen hat, kann es zu einem Zeitproblem kommen.

2. Du machst nur die Änderungen an der Datenbank über ein Script. Alles andere führt höchstens zu Problemen. Ein Import einer alten Struktur in eine neue, kann sehr kompliziert werden. Würde ich nie so machen.

3. Siehe 2.

4. Verstehe ich nicht. Selbst bei deinem Plan macht das doch keinen Sinn. Oder ich durchschaue das gerade nicht.


Also ich würde es so machen:
1. Den Anwender auffordern, vor dem Update eine Sicherung zu machen. Bei kleinen DBs kannst du das auch mit dem Programm machen.
2. Ein Script laufen lassen, dass alle DB-Änderungen durchführt.
3. Ich habe fertig.

Ich würde es so machen:
1. Aktuelle Datenbank kopieren (= 'schnelleres' Backup)
2. Aktuelle Datenbank Shutdown, damit niemand da während des Updates drauf zugreifen kann
3. Struktur in der Datenbank per SQL-Scripte hochziehen
4. Backup/Restore der Datenbank (hab schon erlebt, das sonst einige Strukturänderungen evtl. nicht richtig übernommen werden)
5. Datenbank wieder hochfahren (wg. Shutdown)
6. Wenn alles sauber gelaufen, Kopie der DB löschen nicht vergessen

Geht was schief, kannst du einfach die Kopie und alte Exe nehmen und hast alles schnell rückgängig gemacht.

Die Aussage 'Backup ist Kundensache' finde ich bedenklich, da Kunden zum einen sowas regelmäßig vergessen und zum anderen eine integrierte Sicherheit mittels Backup mehr
Kundenfreundlichkeit zeigt. So ist man halbwegs sicher, das man nichts 'kaputtmacht' und notfalls den alten Zustand wieder herstellen kann.

Zuerst danke für die schnellen Antworten.

Zu jasocul:
Das mit dem Script ist sehr viel aufwand.
Ich muss jedesmal wenn ich etwas an der Datenbank geändert habe, auch meinen Script anpassen.

Zu zuma:

Zitat:

3. Struktur in der Datenbank per SQL-Scripte hochziehen

Bei einer ersten Installation von Programm erstelle ich die Datenbank über SQL-Script (Datenbank.FDB.sql).

Mein Problem ist, ich wollte nicht für jeden änderung der Datenbank an die SQL-Scripte denken müssen.
Mein ansatz war aus der Datenbank ein SQL-Scriptdatei exportieren und die in die Datenbank zu importieren.

Bei MySQL gibt es die möglichkeit ein Dump (SQL-Script) mit dem befehl IF NOT EXIST zu erstellen.
Danach muss ich nur noch denn Dump in die Datenbank zu importieren und siehe da es sind alle änderungen in der Datenbank vorhanden.

Gibt es eine möglichkeit bei Firebird das SQL-Script (Dump) auch mit dem Befehl IF NOT EXIST zu erstellen (aus der Datenbank zu exportieren).

Wenn Deine Dantenbank Autowerte verwendet und Du referenzielle Integritäten zu berücksichtigen hast (was ich hoffe) wirst Du um Scripte längerfristig nicht herumkommen.

Ja die Datenbank hat in jeder Tabelle ein Automatische Inkrement ID.

Gegen SQL-Scripte hab ich ja nix, nur ich hätte die gerne irgend wie automatisiert ohne viel aufwand (wie bei MySQL-Dump).

Wir haben praktisch die selben Grundvorrausetzungen, wie Du (Firebird 2.5, DBExpress, etc...)

Bei uns läuft es so:
In der Datenbank hab ich einen Generator namens "Version". Dieser ist eingentlich nur eine Zahl, die eine Versionsnummer für mich darstellt. Daher weiß ich, welchen Stand die Datenbank hat.
Im Programm habe ich eine Konstante, "Datenbankversion". Diese gibt an, welche Datenbankversion das Programm erwartet.

Beim Start vergleiche ich nun den Wert des Generators mit dem der Konstante.
Fall 1: Generator = Konstante -> Alles in Butter
Fall 2: Generator < Konstante -> Es wird ein Datenbankupdate durchgeführt. Erklär ich gleich.
Fall 3: Generator > Konstante -> Die Datenbank wurde schon mal auf einen höheren Stand konvertiert, als das Programm erwartet (vielleicht auf einem anderen Arbeitsplatz). User davon in Kenntnis setzen und Programm beenden

Das Datenbankupdate läuft so ab.
Erst mal wir gecheckt, ob ich der einzige User bin. Falls nicht, wird der User darüber in Kenntnis gesetzt und gefragt, ob die anderen User rausgeworfen werden sollen (geht seit Firebird 2.5 )

Ich habe den Ist-Stand (Generator) und den Soll-Stand (Konstante). Immer wenn ich eine Änderung an der Datenbank mache während der Entwicklung, kopiere ich das entsprechende DDL-Statement in eine Textdatei. Diese Textdateien liegen in Unterordnern, die durchnummeriert sind.
Hab ich jetzt eine Datenbankversion 3 und das Programm erwartet Version 6, dann weiß ich, ich muss alle Scripte aus den Ordnern 4, 5 und 6 ausführen, um die DB auf den Versionsstand 6 zu bringen.

Wenn ich ein Release mache, setze ich nur die Konstate einen Wert hoch. Und für die nächsten Entwicklungen lege ich einen neuen Unterodner (Nummer + 1) mit einem neuen Script an.

So kann ich aus jedem beliebigen Datenbankstand die DB auf den aktuellen Stand konvertieren. Bei uns gibt es praktisch bei jedem Release eine Datenbankänderung und wir haben locker 20 Releases/Jahr bei rund 600 Usern. Diese Vorgehensweise hat sich als sehr stabil gezeigt.

Die Updateprozeduren sind alle soweit in gekapselt, dass ich sie praktisch ohne Änderung in anderen Produkten einsetzen kann.

Danke für die Info.

Wenn ich mir alle Antworten durchlese, werde ich das so machen müssen.

Wie habt Ihr das mit dem Firebird Server gemacht?

1. Server ist ganz normal installiert und benutzt denn Standard Port
2. Server wird als embeded Server benutzt
3. Server läuft als eigene Instanz auf einem anderem Port
z.B. Windows-Deinste: Firebird Guardian - ProgramnameInstance und Firebird Server - ProgramnameInstance - Port: 43050

BrixxtoN hat folgendes geschrieben:

Wenn ich mir alle Antworten durchlese, werde ich das so machen müssen.

Kannst mir ja den Quellcode für die Funktion abkaufen.

Das hört sich soger gut an.
Ich brauche denn Preis und die Beschreibung der Funktionen.

Dann kann ich das der Geschäftsführung vorlegen und dann wird entschieden.

Dann verlegen wir das mal auf PN.