Delphi-PRAXiS - Delphi IB-Transaktionen

Dann will ich mal noch was Zitieren aus meinem schlauen Buch. :-D

Zitat:

Stichwort Isolation:

Obwohl mehrere Transactionen zur gleichen Zeit zulässig sind, muss jede Transaction völlig unabhängig von anderen ablaufen. Das System muss sich aus Sicht der Transaction so verhalten, als wäre diese Transaction der einzigste Vorgang. .... Er darf für die Zeitdauer seiner aktiven Transaction niemals die Änderungen von anderen Benutzern, die zwangsläufig im Kontex einer anderen Transaction ausgeführt werden, sehen.

Quelle: Andreas Kosch Interbsae DB-Entwicklung mit Delphi

Wenn ich das jetzt richtig sehe verstehst Du die Transaction so, dass Du die Daten holst - befinden sich also im Kontex der Transaction (geholte Daten stehen unter 1). Nun wird änderst Du die Daten und speicherst die Daten (gespeicherte Daten stehen nun unter 2).

Nun schließt Du die Transaction über CommitRetaining, die Transaction speichert die Daten in der DB schließt sich und öffnet sich gleich wieder und holt sich die Daten die unter 1 stehen, somit den alten nicht geänderten Datenmenge. Da du mit CommitRetaining deine active Transaction niemals schließt, können deine Daten auch nie, während das Programm läuft, eine aktuelle Datenmenge erhalten.

Zitat:

Zitat von HaJo

Das das korrekt ist, kann ich mir nicht vorstellen!

Die diese vorgehensweise ist schon korrekt. Nehmen wir mal ein simples Beispiel: Du hast ein Programm in dem Briefe erstellt werden können. Die Abarbeitung sieht vor, Brief schreiben und nach dem alle Briefe geschrieben wurden einen Report zu drucken. Die Daten wurde so gesucht, dass er alle Daten sucht, die noch nicht gedruckt und wo kein Report gedruckt wurde.

Nach jedem Brief den Du geschrieben hast speicherst Du das Datum in der DB und rufst ein Soft Commit auf und die Datenmenge zu erhalten aber trotzdem Daten zu speichern und wenn alle Briefe geschrieben wurden druckst Du den Report und schreibst in alle Datensätze das der Report gedruckt wurde.

Durch das Soft Commit sparst Du Netzwerkresourcen und quälst den DB-Server nicht so, da du nur ein update machst. Da wird ja nur der DS geupdated, die Datenmenge wird ja erhalten. Würdest Du hier jedesmal einen HardCommit machen und dann wieder über Select die Daten laden kostet das enorm Resourcen.

Das war jetzt auf einen einzelnen User bezogen, nun stelle Dir das aber mal in einem Unternehmen vor, wo 100 oder 500 oder mehr User an der DB sitzen. Und alle machen jedes Mal ein HardCommit und im Anschluss machen sie ein Select um die wieder zu laden. Ich hoffe Du kannst Dir vorstellen was das für die DB, den Server und das Netzwerk bedeutet.

Das Beispiel ist wahrscheinlich etwas komisch aber ich denke es veranschautlich warum es Soft Commits gibt.