IB-Transaktionen

[Quake]

Das passiert doch aber nur wenn die Transaktion auf Schnappschuß steht, oder?

[Albi]

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

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

[Albi]

Zitat von Quake:

Das passiert doch aber nur wenn die Transaktion auf Schnappschuß steht, oder?

Genau, dies ist das Standardverhalten der Interbase, ich sehe nur das was da ist.

@HaJo: Ich kann Dir nur empfehlen ein Buch zu kaufen und die Docu zur DB zu lesen. Ansonsten fängst Du an zu schreiben und schreibst und schreibst und kurz bevor du fertig bist und das Prog im Netzwerk testet, stellst sich raus, dass das so nicht geht, da sich die Clients selber behindern. Die Interbase oder jede andere RDM System ist sehr komplizert/komplex. Ist also mit einer Desktop-DB nicht zu vergleichen.