Aus diesem Grunde sollte man ja die Sperren eines Zyklus nicht über Bildschirmeingaben hinaus halten, der Benutzer könnte ja gerade in Pause gehen.

Wenn also der "Select for Update" die Erhöhung und der "Update for current of" in eine Routine (egal ob SQL-Procedure, Service-Programm, o.ä.) gekapselt sind werden die Wartezeiten nicht auftreten und somit auch ohne Commit funktionieren.

Da hier ja die Erhöhung (z.B. Auftrags-/Rechnungs-Nr. o.ä.) im Vordergrund steht sollte kein anderer Zugriff auf diese Information erfolgen.

Wenn ich mir nun einen Commit-Zyklus vorstelle, dann ist das Problem der Satzsperre auch noch verschärft, da ja dieser Zähler in anderen Dateien sicherlich Verwendung finden wird.

Wenn nun der Zähler von einem anderen Prozess während einer Sperre gelesen und verwendet wird ist das ein schwerer Design-Fehler, da der 1. Prozess, der die Sperre hält, immerhin noch eine Rollback-Operation durchführen kann und der vom 2. Prozess gelesene Zähler dann falsch ist.

Was dann ?

ps:

Die Reihenfolge für die Erhöhung ist sowieso egal (es ist nur relevant, was performanter ist), da ich sowieso nicht weiß ob ein 2. Prozess den Wert kurz vor oder nach der Erhöhung liest (das ist wie mit der Katze und dem Gas im geschlossenen Würfel, tot oder nicht tot).