Firebird - Mehrere abhängige SQLs in einer Transaktion

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

[Dejan Vu]

Vielleicht ist der Umstieg von SQL-Server auf FB doch keine so gute Idee.
Ich würde an Deiner/eurer Stelle analysieren, ob es noch weitere Fallstricke gibt (oder ist die Frage/das Problem Bestandteil einer Machbarkeitsstudie?).

[Neutral General]

Zitat von Dejan Vu:

Vielleicht ist der Umstieg von SQL-Server auf FB doch keine so gute Idee.
Ich würde an Deiner/eurer Stelle analysieren, ob es noch weitere Fallstricke gibt (oder ist die Frage/das Problem Bestandteil einer Machbarkeitsstudie?).

Habe nie etwas von einem Umstieg geredet
Wir haben schon immer Firebird benutzt.

Zitat von bepe:

Nie benutzt aber das klingt als suchst du nach SavePoints.

Dachte ich auch für einen Moment, aber die funktionieren halt nur innerhalb einer Transaktion. Sobald ich commite kann ich nicht mehr zurückspringen und nach einem CREATE TABLE muss ich ja scheinbar committen.

Zitat von nahpets:

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

Zitat von Perlsau:

Um eine Firebird-Datenbank-Datei zu sichern, legt man gewöhnlich ein Backup mit dem Firebird-Utility GBak an.

Ich kenne gbak Aber da ich ein Datenbank-Updateverfahren entwickle wo auch mal einige Skripte hintereinander ausgeführt werden ist ein (komplettes) Backup(/Restore) (egal ob arm oder reich) zu viel overhead. Die Ausführungsdauer der meisten Skripte liegt bei unter 1 Sekunde. Für jedes Skript vorher ein Backup einer > 1GB Datenbank anzulegen sprengt das Ganze leider

[jobo]

Zitat von Neutral General:

Aber da ich ein Datenbank-Updateverfahren entwickle wo auch mal einige Skripte hintereinander ausgeführt werden ist ein (komplettes) Backup(/Restore) (egal ob arm oder reich) zu viel overhead.

Das Thema ist wie Du siehst nicht tivial. Ein Grund für die Existenz von Backups ist ja die Möglichkeit, sich gegen fehlerhafte Updates abzusichern.
Wahrscheinlich musst Du Deine Strategie überdenken.

[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