Firebird - Mehrere abhängige SQLs in einer Transaktion

[nahpets]

Schau mal hier: http://entwickler-forum.de/showthrea...d-Transactions

oder hier: http://stackoverflow.com/questions/1...-a-transaction

Kurz: Demnach geht nicht in einer Transaktion.

[Neutral General]

Zitat von nahpets:

Schau mal hier: http://entwickler-forum.de/showthrea...d-Transactions

oder hier: http://stackoverflow.com/questions/1...-a-transaction

Kurz: Demnach geht nicht in einer Transaktion.

Den zweiten Link hab ich auch grad gefunden.
Und was machen ich dann wenn ich ein Skript ausführen möchte (möglicherweise lange Skripte in denen Tabellen erstellt, gedroppt, Daten gelöscht und eingefügt werden)
und bei einem Fehler das Skript zurückrollen will? Das muss doch auf irgendeine Weise möglich sein

[jobo]

Bei DDL musst Du traditionell die Erzeugung von Objekten, Änderung, Löschun eher selbst verwalten.

Du könntest versuchen mit Execute Statement <stmt >with autonomous transaction..
falls das geht, kommst Du durch, falls kein Fehler auftritt, wenn das DDL Fehler wirft, bist Du aber auch nicht viel weiter.

[Neutral General]

Mir kam grad eine böse Idee die ich aber bisher (vielleicht zum Glück?) nicht zum Laufen gebracht habe.
Vielleicht kann ich ja die Delta files misbrauchen?

Code:

alter database begin backup;

-- skript mit commmit nach jedem Befehl

alter database end backup;

Falls dort dann zwischendrin was schief läuft könnte ich ja irgendwie vielleicht die delta Datei löschen und so mein Skript quasi zurückrollen?

[p80286]

Zitat von Neutral General:

Und was machen ich dann wenn ich ein Skript ausführen möchte (möglicherweise lange Skripte in denen Tabellen erstellt, gedroppt, Daten gelöscht und eingefügt werden)
und bei einem Fehler das Skript zurückrollen will? Das muss doch auf irgendeine Weise möglich sein

umdenken. und aus einem Script mehrere machen, wo Du im Fehlerfall zu Fuß wieder aufräumst/ aufräumen kannst.
(Wenn FB alles das könnte was die "großen" können, welche Daseinsberechtigung hätten die dann noch?)


Gruß
K-H

[nahpets]

Also versuchen wir das mit "irgendwie möglich" mal locker zu sehen

1. Script: alles, was mit DDL zu tuen hat. (eine Transaktion)
2. Script: alles, was mit DML zu tuen hat. (eine Transaktion)
3. Script: alles, was im Fehlerfalle erforderlich ist. (eine Transaktion)

Das erste Script wird ausgeführt, tritt ein Fehler auf, sollte ein Rollback ausreichen und Abbruch der Routine.
Fehlerlos durchgelaufen: Commit, zweites Script ausführen.
Zweites Script fehlerfrei: Commit und Ende der Routine.
Zweites Script Fehler aufgetreten: Rollback und drittes Script ausführen.

Im dritten Script muß restlos alles, was im ersten Script gemacht wurde, wieder aus der Datenbank entfernt werden.
Für jedes Create Table ein entsprechendes Drop Table...

Was ist, wenn im dritten Script Fehler auftreten?
Sch..., keine sinnvolle Idee im "Schnellzugriff" vorhanden
Und genau dass wird der größte Teil der anstehenden Arbeit werden. Fehlerresistente Fehlerbeseitigung.

Dazu Frage:

Läuft das im laufenden Betrieb oder hast Du die Datenbank da in alleinigem Vollzugriff?

Wenn Du der "Alleinherrscher" über die Aufgabe bist:

0. Script: Backup der Datenbank erstellen.
1. Script: Wie oben...
2. Script: Wie oben...
3. Script: Restore der Datenbank aus obigem Backup.

[Neutral General]

Zitat von nahpets:

Läuft das im laufenden Betrieb oder hast Du die Datenbank da in alleinigem Vollzugriff?

Wenn Du der "Alleinherrscher" über die Aufgabe bist:

0. Script: Backup der Datenbank erstellen.
1. Script: Wie oben...
2. Script: Wie oben...
3. Script: Restore der Datenbank aus obigem Backup.

Ja ich habe alleinigen Vollzugriff.
Die Sache ist nur die: Ich will nicht bei 20 Skripten 20x eine > 1GB Datenbank sichern und wiederherstellen.
Das dauert dann statt 1 Minute 1 Stunde.

Die Lösung mit dem Rollback-Skript gefällt mir auch nicht sonderlich. Da muss ich alle Skripte ja fast doppelt schreiben

Gibt es nicht tatsächlich eine Möglichkeit das Ganze über Delta Files, bzw. inkrementelle Backups zu lösen? die ich dann zurückspielen, bzw. reverten kann? (Das wären dann ja meistens nur wenige KB)

[nahpets]

Wäre "Datenbanksicherung für Arme" 'ne Alternative?

Datenbankserver runterfahren.
Datenbankdatei per Copy irgendwohin kopieren.
Datenbankserver starten.
Script laufen lassen.
Kopie der Datenbankdatei löschen.

Im Fehlerfalle:
Datenbankserver stoppen.
Originaldatenbankdatei löschen.
Kopie an Stelle der Originaldatenbankdatei.
Datenbankserver starten.

'ne andere Möglichkeit kenn' ich nicht, aber das heißt selbstverfreilich nicht, dass es da nicht doch was besseres geben könnte.

[Perlsau]

Um eine Firebird-Datenbank-Datei zu sichern, legt man gewöhnlich ein Backup mit dem Firebird-Utility GBak an. Dazu muß man weder den Server herunterfahren noch Clients abmelden. Auch für das Restore muß der Server nicht heruntergefahren werden, Clients dürfen währenddessen aber keine mit der Datenbank verbunden sein.

Für das gewöhnliche Kopieren der Datenbank-Datei gilt dasselbe wie für das Restore via GBak: Datenbankserver kann laufen, aber Clients dürfen keine verbunden sein. Dasselbe gilt dann natürlich auch für das gewöhnliche Zurück-Kopieren.

Irgendwo in den Weiten der DP-Threads hatte mir einst ein ausgewiesener Fachmann (entweder Thomas "FB-Evangelist" Steinmaurer oder Holger "IbExpert" Klemt würde ich tippen) den guten, aber kostenlosen Rat erteilt, auf das Kopieren einer Firebird-DB-Datei innerhalb einer Anwendung, die diese Datei nutzt, möglichst zu verzichten, weil nach einem Disconnect womöglich noch eine kurze Zeit irgendwelche Sachen vom Firebird-Server erledigt werden. Bei der Embedded-Variante wäre das vermutlich egal, obwohl hier seit Version 2.5 oder so auch bei Embedded mehrere User auf dieselbe DB-Datei zugreifen können, allerdings mit gewissen Einschränkungen, aber das ist ein anderes Thema.

Und da Firebird komplett kostenlos ist, gibt's auch kein "Backup für Arme"

[nahpets]

@Perlsau

Beim "Backup für Arme" meinte ich das nicht im monetären Sinne, sondern in dem der "ärmlichen" Professionalität meines Vorschlages, um an einem Problem vorbei zu kommen, für das ich keine professionelle Lösung weiß.