Firebird - Mehrere abhängige SQLs in einer Transaktion

[bepe]

Nie benutzt aber das klingt als suchst du nach SavePoints.

[Perlsau]

Um eine Firebird-Datenbank-Datei zu sichern, legt man gewöhnlich ein Backup mit dem Firebird-Utility GBak an. Dazu muß man weder den Server herunterfahren noch Clients abmelden. Auch für das Restore muß der Server nicht heruntergefahren werden, Clients dürfen währenddessen aber keine mit der Datenbank verbunden sein.

Für das gewöhnliche Kopieren der Datenbank-Datei gilt dasselbe wie für das Restore via GBak: Datenbankserver kann laufen, aber Clients dürfen keine verbunden sein. Dasselbe gilt dann natürlich auch für das gewöhnliche Zurück-Kopieren.

Irgendwo in den Weiten der DP-Threads hatte mir einst ein ausgewiesener Fachmann (entweder Thomas "FB-Evangelist" Steinmaurer oder Holger "IbExpert" Klemt würde ich tippen) den guten, aber kostenlosen Rat erteilt, auf das Kopieren einer Firebird-DB-Datei innerhalb einer Anwendung, die diese Datei nutzt, möglichst zu verzichten, weil nach einem Disconnect womöglich noch eine kurze Zeit irgendwelche Sachen vom Firebird-Server erledigt werden. Bei der Embedded-Variante wäre das vermutlich egal, obwohl hier seit Version 2.5 oder so auch bei Embedded mehrere User auf dieselbe DB-Datei zugreifen können, allerdings mit gewissen Einschränkungen, aber das ist ein anderes Thema.

Und da Firebird komplett kostenlos ist, gibt's auch kein "Backup für Arme" :-D

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

Zitat von Dejan Vu (Beitrag 1328229)

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 :gruebel:
Wir haben schon immer Firebird benutzt.

Zitat:

Zitat von bepe (Beitrag 1328181)

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:

Zitat von nahpets (Beitrag 1328180)

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

Zitat:

Zitat von Perlsau (Beitrag 1328183)

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:

Zitat von Neutral General (Beitrag 1328233)

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...:P

Zitat:

CREATE TABLE muss ich ja scheinbar committen.

...:gruebel: 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. :P
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... 8-)

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

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

Zitat von haentschman (Beitrag 1328239)

Moin...:P

Zitat:

CREATE TABLE muss ich ja scheinbar committen.

...:gruebel: 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. :P

Das ganze in eine Transaktion gepackt und gut... 8-)

Zitat:

Zitat von haentschman (Beitrag 1328243)

:P 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 :mrgreen: