AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

To Commit or not to commit

Ein Thema von Zwirbel · begonnen am 8. Sep 2016 · letzter Beitrag vom 9. Sep 2016
Antwort Antwort
Seite 1 von 2  1 2   
Zwirbel

Registriert seit: 17. Aug 2009
64 Beiträge
 
Delphi 10 Seattle Ultimate
 
#1

To Commit or not to commit

  Alt 8. Sep 2016, 10:04
Datenbank: Firebirdd • Version: 3 • Zugriff über: Seattle
Hallo,

das man in einer echten Datenbank (Firebird) z. B. einen Datensatz nicht einfach nur einfügt sondern das ganze noch commiten muss, ist mir klar. Nun stellte ich aber gerade fest, dass ein Commit das ich abgesetzt habe, überhaupt nichts brachte. Ich hatte es einfach mal auskommentiert und trotzdem sind alle Tabellen die ich gefüllt habe ordnungsgemäß aufgefüllt worden. Auch ein paar "ALTER SEQUENCE "%s" RESTART WITH %d" die ich noch abgesetzt habe sind alle in der Datenbank angekommen. Nun frage ich mich, durch welchen Mechanismus ist das passiert?

Ich verwende eine TFDConnection-Komponente (namens "dbsAM_FB") und eine TFDTransaction-Komponente. In dieser ist das Options.AutCommit auf "False" gesetzt. Zum Einfügen der Datensätze verwende ich einen TFDQuery. Datensätze füge ich ein mit "qry_FB.ExecSQL(InsertSQL);".

Was bewirkt denn nun, dass ohne explizites "dbsAM_FB.Commit;" die Operationen (Einfügen und ALTER SEQUENCE) überhaupt nachhaltig sind?

Mal der etwas verkürzte Code, der die Daten per INSERT einträgt:

Delphi-Quellcode:
        tbl_Pdx.TableName := TableNames[i];
        tbl_Pdx.Open;
        try
          try
            tbl_Pdx.First;
            InsertFieldNames := '';
            InsertFieldValues := '';
            qry_FB.SQL.Clear;

            { Zuerst sammeln wir die Felder für das Insert-Statement. }
            for k := 0 to Pred(tbl_Pdx.Fields.Count) do begin
              FieldNameUpper := RenamedField(TableName, tbl_Pdx.Fields[k].FieldName);
              if FieldNameUpper <> 'then begin
                InsertFieldNames := InsertFieldNames + Format('"%s", ', [FieldNameUpper]);
                InsertFieldValues := InsertFieldValues + Format(':%s, ', [FieldNameUpper]);
                FieldNames[k] := FieldNameUpper;
              end else begin
                FieldNames[k] := '';
              end;
            end;
            InsertFieldNames := Copy(InsertFieldNames, 1, Length(InsertFieldNames)-2);
            InsertFieldValues := Copy(InsertFieldValues, 1, Length(InsertFieldValues)-2);
            InsertSQL := Format('INSERT INTO "%s" (%s) VALUES (%s)', [TableName, InsertFieldNames, InsertFieldValues]);
            qry_FB.SQL.Add(InsertSQL);

            { Jetzt sammeln wir die Felder für das "Params". }
            for k := 0 to Pred(tbl_Pdx.Fields.Count) do begin
              FieldNameUpper := tbl_Pdx.Fields[k].FieldName;
              if FieldNameUpper <> 'then begin
                FieldNameUpper := tbl_Pdx.Fields[k].FieldName;
                qry_FB.Params.CreateParam(tbl_Pdx.Fields[k].DataType, FieldNameUpper, ptInput);
              end;
            end;

            { Alle Datensätze der Quelltabelle durchlaufen. }
            for j := 0 to Pred(RecordCount) do begin
              FMeter.CurrentValue := Succ(j);
              Percent := (100 * j) div RecordCount;
              for k := 0 to Pred(tbl_Pdx.Fields.Count) do begin
                if FieldNames[k] = 'then Continue; // Ein Feld das in der Zieltabelle nicht mehr vorhanden ist überspringen

                FieldNameMixed := tbl_Pdx.Fields[k].FieldName;
                FieldNameUpper := FieldNames[k];

                { Nun die Werte je nach Datentyp übertragen von der Quelle ins Ziel }
                case tbl_Pdx.Fields[k].DataType of
                  ftString :
                    if FieldNameMixed <> 'LoginPasswordthen begin
                      qry_FB.ParamByName(FieldNameUpper).AsString := tbl_Pdx.FieldByName(FieldNameMixed).AsString;
                    end else begin
                      qry_FB.ParamByName(FieldNameUpper).AsString := GetStrHashBobJenkins(tbl_Pdx.FieldByName(FieldNameMixed).AsString);
                    end;
                end; // case tbl_Pdx.Fields[k].DataType of
              end; // for k := 0 to Pred(tbl_Pdx.Fields.Count) do

              { Wenn nur simuliert werden soll, keine Daten eintragen. }
              if not chkSimulation.Checked then
                qry_FB.ExecSQL(InsertSQL);
              tbl_Pdx.Next;

              { Daten nur in größeren Brocken an die Datenbank übertragen. }
              if (j mod 5000) = 0 then begin
                if not chkSimulation.Checked then
                  dbsAM_FB.Commit;
              end;
            end; // for j := 0 to Pred(tbl_Pdx.RecordCount) do

            if FStoped then Break; // Bricht die komplette Konvertierung sofort ab
            FSkip := False;
          finally
            tbl_Pdx.Close;
          end;
Danke im Voraus. Gruß, Markus
  Mit Zitat antworten Zitat
Benutzerbild von Neutral General
Neutral General

Registriert seit: 16. Jan 2004
Ort: Bendorf
5.147 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#2

AW: To Commit or not to commit

  Alt 8. Sep 2016, 10:11
Die Queries haben noch ne Property AutoCommit die standardmäßig auf true steht
Michael
"Programmers talk about software development on weekends, vacations, and over meals not because they lack imagination,
but because their imagination reveals worlds that others cannot see."
  Mit Zitat antworten Zitat
Zwirbel

Registriert seit: 17. Aug 2009
64 Beiträge
 
Delphi 10 Seattle Ultimate
 
#3

AW: To Commit or not to commit

  Alt 8. Sep 2016, 10:15
Die Queries haben noch ne Property AutoCommit die standardmäßig auf true steht
Meine Query-Komponente sieht so aus:
Delphi-Quellcode:
object qry_FB: TFDQuery
  Connection = dbsAM_FB
  Left = 497
  Top = 609
end
Das Property "UpdateUptions.AutoCommitUpdates" steht also noch auf dem Defaultwert "False".

Allerdings entdecke ich gerade, dass das Property "Transaction" der Query nicht gesetzt ist. Das sollte man sicherlich tun.
  Mit Zitat antworten Zitat
Zwirbel

Registriert seit: 17. Aug 2009
64 Beiträge
 
Delphi 10 Seattle Ultimate
 
#4

AW: To Commit or not to commit

  Alt 8. Sep 2016, 12:05
Die Queries haben noch ne Property AutoCommit die standardmäßig auf true steht
Leider liefert die in Delphi integrierte Hilfe mal wieder nichts brauchbares wenn man Infos zu Properties einer Kompo haben will. Aber Google spuckt dann einen Link mit brauchbaren Infos aus http://developers-club.com/posts/273549/. Und bei mir ist "Options.AutoStart" in der Tat "True", allerdings ist "Options.AutoStop" auf "False", der Default wäre aber "True", kann mich nicht entsinnen das verändert zu haben. "Options.DisconnectAction" steht auf "xdCommit". Also dürfte das der Auslöser dafür sein, dass a) automatisch Transaktionen starten und b) spätestens wenn die Verbindung beendet wird, dann wird commited.

Wieder was gelernt.
  Mit Zitat antworten Zitat
Benutzerbild von Sherlock
Sherlock

Registriert seit: 10. Jan 2006
Ort: Offenbach
3.522 Beiträge
 
Delphi 10.3 Rio
 
#5

AW: To Commit or not to commit

  Alt 8. Sep 2016, 12:10
Übrigens: DDL braucht im Gegensatz zu DML kein Commit. Kurz und vereinfacht gesagt: Alles was die Struktur ändert kann ohnehin nicht Rückgängig gemacht werden, demzufolge spart man sich die Commits. Und ein Alter irgendwas ändert die Struktur...

Sherlock
Geändert von Sherlock (Morgen um 16:78 Uhr) Grund: Weil ich es kann
  Mit Zitat antworten Zitat
Zwirbel

Registriert seit: 17. Aug 2009
64 Beiträge
 
Delphi 10 Seattle Ultimate
 
#6

AW: To Commit or not to commit

  Alt 8. Sep 2016, 12:12
Übrigens: DDL braucht im Gegensatz zu DML kein Commit. Kurz und vereinfacht gesagt: Alles was die Struktur ändert kann ohnehin nicht Rückgängig gemacht werden, demzufolge spart man sich die Commits. Und ein Alter irgendwas ändert die Struktur...
Danke für den Hinweis. Gruß, Markus
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
16.681 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#7

AW: To Commit or not to commit

  Alt 8. Sep 2016, 12:19
Übrigens: DDL braucht im Gegensatz zu DML kein Commit. Kurz und vereinfacht gesagt: Alles was die Struktur ändert kann ohnehin nicht Rückgängig gemacht werden, demzufolge spart man sich die Commits. Und ein Alter irgendwas ändert die Struktur...
AFAIK kann das Oracle.
Oracle hat auch einen "Abfalleimer" für gelöschte Tabellen.
Wenn man sich wundert das die Datenbank nicht kleiner wird sollte man die Tabellen im "Abfalleimer" entgültig löschen.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Zwirbel

Registriert seit: 17. Aug 2009
64 Beiträge
 
Delphi 10 Seattle Ultimate
 
#8

AW: To Commit or not to commit

  Alt 8. Sep 2016, 12:28
Übrigens: DDL braucht im Gegensatz zu DML kein Commit. Kurz und vereinfacht gesagt: Alles was die Struktur ändert kann ohnehin nicht Rückgängig gemacht werden, demzufolge spart man sich die Commits. Und ein Alter irgendwas ändert die Struktur...
Nun da ich explizit startende Transactions ausgeschaltet habe und das "ALTER SEQUENCE "%s" RESTART WITH 0" ohne eine eingeleitete Transaction absetzen will kriege ich eine Exception:
Delphi-Quellcode:
  226: 08.09.2016 13:16:33: Error: @@@
Modul: [FireDAC][Phys][FB]Dynamic SQL Error
SQL error code = -901
invalid transaction handle (expecting explicit transaction start)
ErrorId: 1008
Msg: TfrmAMU.ClearTables: Table: [TA_AssetBlock]
Error: [FireDAC][Phys][FB]Dynamic SQL Error
SQL error code = -901
invalid transaction handle (expecting explicit transaction start)
Nun habe ich auch um das ganze ALTER SEQUENCE Gedöns eine Transaction gestartet und dann klappt es wieder.
  Mit Zitat antworten Zitat
tsteinmaurer

Registriert seit: 8. Sep 2008
Ort: Linz, Österreich
527 Beiträge
 
#9

AW: To Commit or not to commit

  Alt 8. Sep 2016, 14:34
Zitat:
Übrigens: DDL braucht im Gegensatz zu DML kein Commit.
Hier unterscheidet sich Firebird von Oracle. In Firebird muss grundsätzlich DDL auch committed werden. Wird halt oft automatisch gemacht, z.b. durch AUTODLL in isql oder halt auch AutoCommit Einstellungen im Client.

Thomas
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.868 Beiträge
 
Delphi 2010 Enterprise
 
#10

AW: To Commit or not to commit

  Alt 8. Sep 2016, 15:04
Zitat:
Übrigens: DDL braucht im Gegensatz zu DML kein Commit.
Hier unterscheidet sich Firebird von Oracle. In Firebird muss grundsätzlich DDL auch committed werden. Wird halt oft automatisch gemacht, z.b. durch AUTODLL in isql oder halt auch AutoCommit Einstellungen im Client.

Thomas
Sowas hatte ich für Firebird auch im Kopf, war mir aber nicht sicher.

Wichtig für die Arbeit mit Systemen, die sich wie Oracle verhalten, ist vielleicht im Einzelfall bei DDL ohne Autocommit:
DDL macht eigenständig ein Commit, man kann es nicht verhindern, deswegen "braucht" es kein DDL.
Ignoriert man das, führt es leicht zu nicht gewollten Daten-Commits.
Gruß, Jo
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:35 Uhr.
Powered by vBulletin® Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2020 by Daniel R. Wolf