Wie werden Daten speichern

[NoName1]

Guten Tag,
ich habe in einem Buch für Interbase gelesen, dass Daten nur im Rahmen einer Transaktion gespeichert werden können und sollen.
Zur Zeit speicher ich die Daten einzelner Spalten so:

Delphi-Quellcode:

dtmdMain.DoStartTransaction;
 if dtmdMain.arbeitsplan.State in [dsEdit] then
 dtmdMain.arbeitsplan.Post;
 dtmdMain.ibtrnsctnLoge.CommitRetaining;

In der Procedure "dtmMain.DoStartTransaction" geschieht folgendes:

Delphi-Quellcode:

procedure TdtmdMain.DoStartTransaction;
begin
  if not ibtrnsctnLoge.InTransaction then ibtrnsctnLoge.StartTransaction;
end;

Meine Fragen dazu sind folgende:
Ist es nicht sinnvoller die Speicherung so zu implementieren.

Delphi-Quellcode:

  if dtmdMain.arbeitsplan.State in [dsEdit] then
  begin
    dtmdMain.DoStartTransaction;
    dtmdMain.arbeitsplan.Post;
    dtmdMain.ibtrnsctnLoge.CommitRetaining;
  end;

und, wie ist es sinnvoller, wie ist Eurer Verfahren?
Vielen Dank für Eure Hilfen.

[Delphi.Narium]

Nein.

'ne Transaktion beginnt man vor dem Ändern von Daten und beendet sie nach dem Ändern von Daten.

War die Änderung korrekt, so wird Commit aufgerufen, war sie nicht korrekt, wird sie mit Rollback verworfen.

Die von Dir zitierte Prozedur prüft nur, ob nicht bereits eine Transaktion geöffnet wurde, damit man sie nicht (beliebig tief) verschachtelt werden, sondern immer nur eine Transaktion zu einer Zeit aktiv ist.

Sinngemäß:

Delphi-Quellcode:

try
  StartTransaction;
  Edit;
  FieldByName('irgendwas').AsString := 'wasweißich';
  ...
  Post;
  Commit;
except
  on e : Exception do begin
    Rollback;
  end;
end;

Mal mit dem Thema Datenbank Transaktionshandling auseinandersetzen, und zwar losgelöst von einer konkreten Datenbank und der Implementierung von Delphiroutinen zu einer bestimmten Datenbank.

Also: Zuerst Allgemeinwissen verschaffen, dann an die konkrete Umsetzung gehen.

Und nein, es ist nicht trivial.
Bei Fragen: fragen ;-)

[NoName1]

Delphi.Natrium,
vielen Dank für die Antwort.
Ich vergas eines zuerwähnen, die Grundlage der Datendarstellung ist ein Formular mit Dantenbankfeldern.
Die Datenbankfelder sind mit einer DataSource verknüpft. Das Formular hat keinen Button über den
die Datenspeicherung erfolgt. Gespeichert wird immer, wenn das Datenbankfeld vererlassen wird (OnExit).
Wenn nun der Wert eines Feldes geändert wurde, dann befindet sich die Datenbank ja im Edit-Modus
und es muss nicht noch nocheinmal nach Edit geprüft werden.

Beispiel:

Delphi-Quellcode:

procedure TMSFMArbeiten.edtSAMMLUNGExit(Sender: TObject);
begin
  SpeicherTageGlobal; // hier wird nun der Code zum Speichern aufgerufen.
end;

Du hast selbstverständlich Recht mit Deinem Code. So speicher ich auch Werte in die Tabelle, wenn ich Daten per Procedure übergebe.

Und wie schon erwähnt, ich vergas etwas zu erwähnen.

[Delphi.Narium]

Das ändert doch nichts.

Eingabefelder haben 'ne DataSource. 'ne DataSource hat 'nen DataSet. Ein DataSet hat ein Ereignis BeforeEdit.

Was spricht dagegen, dieses Ereignis zu nutzen und dort die Transaktion zu beginnen?

Weitere Ereignisse können für das Beenden bzw. das Verwerfen der Änderungen genutzt werden.

[jobo]

Meine Meinung dazu:
explizite clientseitige Transaktionkontrolle macht alles nur anstrengender.
Der mögliche Nutzen entsteht erst, wenn ich Arbeitsabläufe bereitstellen (muss), die über das Editieren von mehr als einem Datensatz hinweg reichen ohne das explizite Commit.
Auch dann kann ich alles DB-seitig belassen, wenn die fragliche Aktion mittels SP umsetzbar ist.
Erst danach brauch ich vielleicht clientseitige Transaktionskontrolle oder vielleicht auch die Frage, ob man seine Arbeitsabläufe / DB Design umstellen sollte.

[Schokohase]

Zitat:

Zitat von jobo (Beitrag 1429304)

Meine Meinung dazu:
explizite clientseitige Transaktionkontrolle macht alles nur anstrengender.

Es ist nur dann anstrengend, wenn man sich die Datenverbindungen auf der Form zusammenklimpert.

Bei einer vernünftigen Trennung* hat man da keinerlei Probleme.

* Daten von der/den Query/Queries in ein Objekt schreiben, mit dem Objekt arbeiten und dann das Objekt per Statement/s innerhalb einer Transaktion in die Datenbank schreiben.

[haentschman]

Zitat:

* Daten von der/den Query/Queries in ein Objekt schreiben, mit dem Objekt arbeiten und dann das Objekt per Statement/s innerhalb einer Transaktion in die Datenbank schreiben.

+ 1 :thumb:

[jobo]

Mit "anstrengend" meinte ich Resourcenintensiv, also weniger die Herangehensweise beim Programmieren.
Der Server verwaltet sowieso Transaktionen und wenn der Client hergeht und das selber "übernimmt", wird es halt "anstrengender" für den Server. Darauf würde ich mich runterhandeln lassen.
Aber damit müssen wir auch nicht den Thread hier sprengen.

[Schokohase]

Zitat:

Zitat von jobo (Beitrag 1429309)

Mit "anstrengend" meinte ich Resourcenintensiv, also weniger die Herangehensweise beim Programmieren.
Der Server verwaltet sowieso Transaktionen und wenn der Client hergeht und das selber "übernimmt", wird es halt "anstrengender" für den Server. Darauf würde ich mich runterhandeln lassen.
Aber damit müssen wir auch nicht den Thread hier sprengen.

Dann aber auch bitte fachlich korrekt.

Egal wie du mit den Transaktionen umgehst, der Server verwaltet die in jedem Fall. Der Client kann nur sagen, dass die Transaktion für mehrere Statements gelten soll. Der Client übernimmt hier also gar nichts.