Firebird - Mehrere abhängige SQLs in einer Transaktion

[haentschman]

Moin...

Zitat:

CREATE TABLE muss ich ja scheinbar committen.

... Entweder habe ich das mißverstanden oder was übersehen. Du bemängelst das in einem Script kein Datenbankerzeugen und Tabellen Erstellen stattfinden kann. (Firebird)... Einspruch euer Ehren.
Script auf das wesentliche gekürzt:

Code:

SET SQL DIALECT 3;

SET NAMES NONE;

SET CLIENTLIB 'C:\Program Files\Firebird\Firebird25\DLL32\fbclient.dll';

CREATE DATABASE 'firma-server /3025:D:\tmp\Bla.FDB'
USER 'SYSDBA' PASSWORD 'masterkey'
PAGE_SIZE 16384
DEFAULT CHARACTER SET NONE COLLATION NONE;



/******************************************************************************/
/****                               Domains                                ****/
/******************************************************************************/

CREATE DOMAIN ID AS
INTEGER
NOT NULL;

CREATE DOMAIN STRING30 AS
VARCHAR(30)
NOT NULL;

/******************************************************************************/
/****                              Generators                              ****/
/******************************************************************************/

CREATE GENERATOR ID_GEN;
SET GENERATOR ID_GEN TO 99;

/******************************************************************************/
/****                                Tables                                ****/
/******************************************************************************/

CREATE TABLE T_MASTER_DEVICE_TYPES (
    ID                    ID,
    F_DEVICE_TYPE_ID      ID,
    F_DEVICE_TYPE_STRING  STRING30
);

INSERT INTO T_MASTER_DEVICE_TYPES (ID, F_DEVICE_TYPE_ID, F_DEVICE_TYPE_STRING) VALUES (1, 0, 'Blübbchen');

COMMIT WORK;

/******************************************************************************/
/****                             Primary Keys                             ****/
/******************************************************************************/

ALTER TABLE T_MASTER_DEVICE_TYPES ADD CONSTRAINT PK_T_MASTER_DEVICE_TYPES_1 PRIMARY KEY (ID);

/******************************************************************************/
/****                               Indices                                ****/
/******************************************************************************/

/******************************************************************************/
/****                               Triggers                               ****/
/******************************************************************************/


SET TERM ^ ;



/******************************************************************************/
/****                         Triggers for tables                          ****/
/******************************************************************************/

/* Trigger: T_MASTER_DEVICE_TYPES_BI */
CREATE OR ALTER TRIGGER T_MASTER_DEVICE_TYPES_BI FOR T_MASTER_DEVICE_TYPES
ACTIVE BEFORE INSERT POSITION 0
AS
begin
  if (new.id is null) then
    new.id = gen_id(id_gen,1);
end
^

SET TERM ; ^

COMMIT WORK;

Das ganze in eine Transaktion gepackt und gut...

[mkinzler]

Das COMMIT ist das Zauberwort. Wenn ich den TE richtig verstanden habe möchte er ja alles in einer Transaktion haben und das geht nicht.

[haentschman]

Wie du aber siehst braucht es nach dem CREATE DATABASE kein COMMIT vor dem CREATE TABLE. Dann kann das Script doch in einer Transaktion laufen oder? Im Script wird nach den einzelnen Datentabellen commited weil ich das so eingestellt habe. Die Commits könntest du auch weglassen...insbesondere das letzte COMMIT weil das von außen durchgeführt wird.

Frage: Wir reden wirklich über Script (IBCScript) und nicht mehrere SQL Anweisungen (IBCQuery) nacheinander?

[Neutral General]

Zitat von haentschman:

Moin...

Zitat:

CREATE TABLE muss ich ja scheinbar committen.

... Entweder habe ich das mißverstanden oder was übersehen. Du bemängelst das in einem Script kein Datenbankerzeugen und Tabellen Erstellen stattfinden kann. (Firebird)... Einspruch euer Ehren.

Das ganze in eine Transaktion gepackt und gut...

Zitat von haentschman:

Wie du aber siehst braucht es nach dem CREATE DATABASE kein COMMIT vor dem CREATE TABLE. Dann kann das Script doch in einer Transaktion laufen oder? Im Script wird nach den einzelnen Datentabellen commited weil ich das so eingestellt habe. Die Commits könntest du auch weglassen...insbesondere das letzte COMMIT weil das von außen durchgeführt wird.

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:

1) CREATE TABLE DUMMY_TABLE(ID INTEGER, NAME VARCHAR(80))
2) INSERT INTO DUMMY_TABLE (ID, NAME) VALUES (1, 'Hans')

Probiers wirklich mal aus! Ich dachte genauso wie du bis gestern

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

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ß.

[Neutral General]

Zitat von 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

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. Bin grad am probieren. Es läßt mir keine Ruhe. Das würde auch mein Konzept auf den Kopf stellen...

I am not amused... 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.