Problem beim Erzeugen einer Tabelle in einer Transaktion

[Deep-Sea]

Morgen, ich hab' da mal wieder ein nettes Problemchen.

Ich wollte folgendes tun:

Code:

1. Transaktion starten.
2. Tabelle XYZ mittels SQL erzeugen.
3. Datensatz in Tabelle XYZ mittels SQL hinzufügen.
4. Transaktion abschließen.

IMHO sieht das ya ganz logisch aus. Jedoch tritt bei Punkt 3 der Fehler auf, dass die Tabelle XYZ nicht existiert. Ich müsste, damit dies funktioniert, die Transaktion zwischen 2. und 3. abschließen und eine neue starten. Doch dann brauch ich auch keine Transaktionen mehr.
Werden die Befehle für Datendefinition im Bezug auf Transaktionen anders behandelt als Abfragen und Manipulationsbefehle?

Nebenbei: Ich nutze von Firebird sowohl die Embedded-Variante als auch den Server.

Schon mal danke für die Antworten :-D

[mkinzler]

Die Tabelle wird erst beim Commit angelegt. Vorher kann man also nicht auf diese zugreifen.

[Deep-Sea]

War mir leider schon fast klar. Ist doch aber sch****.
Es geht nämlich darum, dass ich bei einer neuen Version der Software natürlich die vorhandene Datenbank anpassen muss. Wenn also eine neue Tabelle erzeugt werden muss, muss ich das ya tun. Aber wenn beim Update ein Fehler auftritt, will ich ya eigentlich, dass er nicht halbe Sachen in die Datenbank schreibt.
Und wie löst man nun sowas, wenn die ach so tollen Transaktionen da nicht helfen? :|

[mkinzler]

Erzeuge eine neue Datenbank und kopiere anschliessend den Inhalt der alten in diese

[automatix]

Hallo!
Ist dies wirklich so bei Firebird? Ich habe hier leider kein Firebird im Zugriff aber bei DB2 und Oracle funktioniert z. B. folgendes mit Delphi 2006:

Delphi-Quellcode:

var
  ta: TTransactionDesc;
begin
  try
    SQLConnection1.Connected := True;
    try
      ta.TransactionID := 1;
      ta.GlobalID := 0;
      ta.IsolationLevel := xilREADCOMMITTED;
      SQLConnection1.StartTransaction(ta);
      SQLQuery1.SQL.Text := 'create table TEMP.TEST (id integer)';
      SQLQuery1.ExecSQL;
      SQLQuery1.SQL.Text := 'insert into TEMP.TEST (ID) values (1)';
      SQLQuery1.ExecSQL;
      SQLConnection1.Commit(ta);
    except
      SQLConnection1.Rollback(ta);
      raise;
    end;
  finally
    SQLConnection1.Connected := False;
  end;

Was nach meinem Verständnis einer Transaktion auch vollkommen korrekt ist.
Denn eigentlich sollte es so sein, dass man innerhalb einer Transaktion auch alle Änderungen (insert, update, delete, create, drop etc.) der eigenen Tansaktion auch sehen sollte.
Gibt es da bei Firebird vielleicht Konfigurationsoptionen? Oder anderen IsolationLevel xilDIRTYREAD probieren?

Ansonsten Tabellen erzeugen, Daten einfügen. Sollte dabei etwas schief gehen wieder ein drop table.

Grüße

[Sherlock]

Oracle kennt kein Transaktionsmanagement bei DDL.

Und ich glaube, daß das bei anderen DBs nicht anders sein dürfte.

Sherlock

[automatix]

Hallo!
Ist jetzt OT. Aber bei mir funktioniert der oben gezeigte Code mit DB2 V7 / V8 und Oracle 9i. Gerade noch getestet. Bei Oracle hatte ich nur mit 'truncate table' Probleme, der schließt nämlich einfach eine offene Transaktion.

Grüße

[Sherlock]

Mach doch dann bitte ein Rollback, und sag mir ob die Tabelle danach immer noch existiert, oder nicht.



Danke.
Sherlock

Edit:
Oracle:
http://download.oracle.com/docs/cd/B...0/transact.htm
Daraus:

Zitat:

A transaction begins with the first executable SQL statement. A transaction ends when it is committed or rolled back, either explicitly with a COMMIT or ROLLBACK statement or implicitly when a DDL statement is issued.

MySQL:
http://forge.mysql.com/wiki/MySQL_In...ion_management

Zitat:

Similarly, DDL statements are not transactional, and therefore a transaction is (almost) never started for a DDL statement. But there's a difference between a DDL statement and an administrative statement: the DDL statement always commits the current transaction (if any) before proceeding; the administrative statement doesn't.

Sherlock

[automatix]

Hallo!
Ja, diesbezüglich hast Du Recht. Somit funktioniert der Code zwar, aber das der Rollback im Fehlerfalle für 'create table' funktionslos ist wurde von mir nicht bedacht und somit für den TE auch nicht zu gebrauchen. :(
Bleibt nur im Fehlerfalle für alle 'create table' dann 'drop table' auszuführen.

Grüße

[Deep-Sea]

Als "Datenbank-Neuling" fragt man sich, für was Transaktionen gut sein sollen. Dann weiß man es und wenn man es mal wirklich braucht, kann man es nicht nutzen :roll: ...

Zitat:

Zitat von automatix

Bleibt nur im Fehlerfalle für alle 'create table' dann 'drop table' auszuführen.

Ya, ich muss dann nur noch herausfinden, ob in dem SQL-Skript auch eine Tabelle erzeugt wird. Genau das gleiche dann wohl auch bei Generatoren, Triggern, etc. :wall:

(Oder ich handel nach dem Firmenmotto: In der Praxis wird schon kein Fehler auftreten :mrgreen: ...)