Firebird - Mehrere abhängige SQLs in einer Transaktion

[haentschman]

Eben gesehen:

Zitat:

for (int i=0; i < SqlStatements.Count; i++) // List<string> SqlStatements
{
FbCommand cmd = new FbCommand(SqlStatements[i], connection, trans);
cmd.ExecuteNonQuery();
}

...die SQL Statements als Querys hintereinander und nicht als Script. Das sind 2 Paar Schuhe. In deinen DB Komponenten gibt es bestimmt eine Script Komponente. Der übergibst du das Script...fertsch.

Zitat:

In IBExpert läuft sowas natürlich. Selbst ohne das commit work; zwischendurch, aber nur weil IBExpert (scheinbar) implizit an diesen Stellen committed.
Erstell mal in deinem eigenen Code eine Transaktion und versuch diese beiden Befehle hintereinander in dieser Transaktion auszuführen ohne zwischendurch zu committen:

Falsch...:P Ich führe dieses Script auch in der Anwendung aus. Mit der Scriptkomponente und nicht als Querys.

[Neutral General]

Ohne 100%ig sicher zu sein: Aber was glaubst du was die Skriptkomponente sonst macht?

Dann versuch mal in der Skriptkomponente eine Tabelle zu erstellen, Daten einzufügen und danach provozier einen SQL fehler im 3. Befehl und dann machst du ein Rollback.
Ziemlich sicher dass die Tabelle trotzdem da sein wird

[haentschman]

Zitat:

Dann versuch mal in der Skriptkomponente eine Tabelle zu erstellen, Daten einzufügen und danach provozier einen SQL fehler im 3. Befehl und dann machst du ein Rollback.
Ziemlich sicher dass die Tabelle trotzdem da sein wir

:gruebel: Auch wenn eine Transaktion drumherum ist? ...muß ich echt nochmal bei Gelegenheit prüfen. Ich klinke mich dann mal aus bis ich es definitiv weiß. :zwinker:

[Neutral General]

Zitat:

Zitat von haentschman (Beitrag 1328258)

Zitat:

Dann versuch mal in der Skriptkomponente eine Tabelle zu erstellen, Daten einzufügen und danach provozier einen SQL fehler im 3. Befehl und dann machst du ein Rollback.
Ziemlich sicher dass die Tabelle trotzdem da sein wir

:gruebel: Auch wenn eine Transaktion drumherum ist?

Ja. Probiers bitte wirklich mal :)
Falls es DOCH klappt dann bin ich allerdings verwirrt und irgendwas stimmt hinten und vorne nicht.
Aber nach allem was ich seit gestern gelesen/gelernt habe dürfte das selbst mit Transaktion außenrum nicht funktionieren.

[haentschman]

Zitat:

Aber nach allem was ich seit gestern gelesen/gelernt habe dürfte das selbst mit Transaktion außenrum nicht funktionieren.

...ich lerne auch gern dazu. :P Bin grad am probieren. Es läßt mir keine Ruhe. Das würde auch mein Konzept auf den Kopf stellen...:roll:

I am not amused... :roll: Tatsächlich bleiben die Tabellen trotz Rollback zurück. Suuupiii! Ich muß auch das Konzept ändern.

Workaround:
Da es ja um die komplette Erzeugung der Datenbank geht, empfehle ich das Script in einem TRY / EXCEPT Block laufen zu lassen und im Fehlerfalle die erzeugte Datenbank, nach einem DISCONNECT zu löschen.

[Neutral General]

Zitat:

Zitat von haentschman (Beitrag 1328263)

I am not amused... :roll: Tatsächlich bleiben die Tabellen trotz Rollback zurück. Suuupiii! Ich muß auch das Konzept ändern.

Workaround:
Da es ja um die komplette Erzeugung der Datenbank geht, empfehle ich das Script in einem TRY / EXCEPT Block laufen zu lassen und im Fehlerfalle die erzeugte Datenbank, nach einem DISCONNECT zu löschen.

Willkommen im Club :D
Leider geht es bei mir NICHT um die komplette Erzeugung einer Datenbank sondern um das erweitern/updaten einer schon vorhandenen aktiven Kundendatenbank mit Daten.
Von daher funktioniert dein Workaround bei mir leider nicht :(

[Lemmy]

Zitat:

Zitat von Neutral General (Beitrag 1328279)

Leider geht es bei mir NICHT um die komplette Erzeugung einer Datenbank sondern um das erweitern/updaten einer schon vorhandenen aktiven Kundendatenbank mit Daten.

ähm...

nur mal so von Leidensgenosse zu Leidensgenosse:
Hat dein Arbeitgeber eine so gute Haftpflichtversicherung? Selbst ein triviales CREATE SEQUENCE ohne vorhergehende Datensicherung auf Kundendatenbanken los zu lassen ist... mir fehlen gerade die Worte...

Wenn ich beim Kunden am Rechner bin und selbst dann wenn mir der Kunde versichert, dass er gerade eben eine Datensicherung gemacht hat, der kann mir auch gerne die Datei zeigen, bevor ich auch nur ein Select * from rdb$Database absetze wird eine Datensicherung gemacht. Immer. Grundsätzlich. Und ganz speziell Freitag Nachmittag wenn ich eigentlich den Rechner runter fahren wollte und dann ruft der Kunde noch an :-(

Schon allein aus dem Grund um dem Kunden anschließend beweisen zu können, dass er den Fehler gebaut hat und nicht mein Select * from X an seinem Datenverlust schuld ist.


Und nein: Nicht alle Kunden sind so. Aber einer reicht.

Daher ist die einzig richtige Vorgehensweise:
1. Datensicherung durchführen
2. Datensicherung PRÜFEN! (d.h. in einem temp-Verzeichnis die Datenbank wieder herstellen - weil Firebird div. Fehler erst dann fest stellen kann, wenn er die Datenbank neu schreibt) Wenn Du die Datensicherung nicht restoren kannst, dann hast du keine Datensicherung!
3. Dann (und erst dann) Script einspielen (sicher dass Du den Punkt 2 der Liste nicht übersehen hast?)
Bei unseren Datenbanken (um die 400 MB) braucht das rund ne Minute, bei über 1 GByte je nach Server noch mal deutlich länger. Das ist nicht schön. Aber hast Du schon mal dran gedacht, wie lange es dauert die Daten noch mal einzugeben?

Grüße

[Neutral General]

Es werden regelmäßig automatische Backups der Kundendatenbank gemacht.
Das Problem ist nur, dass die Datenbank nach eine Skriptfehler in einem (mehr oder weniger) undefinierten Zustand ist,
den man im besten Fall durch das zurückspielen einer Datensicherung oder das manuelle korrigieren der Datenbank bzw. das manuelle Ausführen des restlichen Skripts beheben kann.

Jetzt bleibt wohl nichts anderes übrig als eine Datensicherung zurückzuspielen wenn was schief läuft aber falls es so funktioniert hätte wie ich dachte und man bedingungslos komplette Skripte zurückrollen könnte dann wäre ein Fehler in einem Skript deutlich harmloser und man müsste bloß den Fehler beheben und das Skript erneut ausführen. So war jedenfalls meine Vorstellung.

[jobo]

Wenn es so ist-Einzelfall-, dann brauchst Du ein Strukturbild (DDL Script) der Kundendb.
Daraufhin musst du gezielt ein (Reparatur)Skript anlegen. Also Reparatur der Struktur.
Alles was dann kommt, die Inhalte, da kannst Du nach Lust und Laune mit Transaktionen / Rollbacks arbeiten. Darauf ist das Konzept ja ausgelegt.

Falls Du ein universelles Update Programm erstellst, wirst Du sicher eine Menge Abnehmer dafür finden.

[Dejan Vu]

Pseudocode:

Code:

try
{
  foreach (IRevertableScript script in scripts)
  {
    ExecuteScript(script.SetupScript);
    revertable.Add(script);
  }
catch
{
  foreach (IRevertableScript scriptToUndo in revertable)
  {
     ExecuteScript(script.TeardownScript);
  }
}

Anstatt also einfach strings auszuführen, erstellst Du also pro 'Script' ein Objekt, bestehend aus zwei Skripten: Ein 'SetupScript' und ein 'TeardownScript', wobei das TeardownScript quasi die Umkehrfunktion des 'SetupScript' ist.
Also: Create Table => Drop Table etc.

Vermutlich muss man die Teardowns in umgekehrter Reihenfolge ausführen. Für einfache Sachen geht das und viele DB-Migratoren machen das auch so (z.B. der von EF)

Das Konzept an sich ist ja sprachenunabhängig.