Firebird - Mehrere abhängige SQLs in einer Transaktion

[Neutral General]

Hallo,

Ich verzweifel hier langsam :(
Ich möchte eine Liste von SQL-Befehlen hintereinander in der gleichen Transaktion ausführen.
Wenn ich allerdings ein CREATE TABLE ausführe (erfolgreich) und danach ein INSERT in diese Tabelle machen will,
schlägt das INSERT fehl weil die vorher erstellte Tabelle angeblich nicht existiert:

Code:

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

  trans.Commit();
}
catch(FbException ex)
{
  trans.Rollback();
}

Kann mir jemand sagen was ich falsch mache?

(PS: Ich weiß, dass es FbBatchExecution gibt, aber das reicht für meine Zwecke nicht, ich muss es von Hand machen)

Crosspost: http://www.entwickler-ecke.de/viewtopic.php?p=698278#

[jobo]

Ich kenne Firebird am ehesten von ein paar Tests mit Flamerobbin.
Muss man da nicht nach einem Create Table auch commiten? Ich weiß es nicht genau auswendig.

Aber DML und DDL werden von verschiedenen Systemen ganz unterschiedlich gehandhabt.

Ein DDL (z.B.) create table macht in Oracle bspw. implizit ein commit.
Letztlich ist es ja auch so, dass in der DB selbst, also im eigenen Dictionary die Tabellen, Spalten, etc. pp eingetragen werden (müssen). Das geschieht bei Oracle zwar mit autonomen TR, aber trotzdem wird zuvor datentechnisch reiner Tisch gemacht.

Also evtl. musst Du alle DDL zu Anfang mit commit durchführen. Falls FB Zwischenschritte unterstützt, kannst Du Dir das vielleicht zunutze machen und bei einem Fehler trotzdem bis zum allerersten Anfang zurückrollen.

[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:

Zitat von nahpets (Beitrag 1328157)

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.

[p80286]

Zitat:

Zitat von Neutral General (Beitrag 1328163)

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

[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? :stupid: :duck:

[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:

Zitat von nahpets (Beitrag 1328169)

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.