Zitat Zitat von dibe Beitrag anzeigen
Comit wurde, und das meine ich ernst, bisher nicht gebraucht. Und der Aufwand, dies in die alte Anwendung ein zu bauen, wäre imens! Daten Journalisieren wir (teilweise). Aber nie um 'transaktionen' zurück zu drehen, das konnte die Software, in der von uns benötigten Form, schon immer.
Commit ist nicht nur Transaktionssteuerung sondern steuert auch die Satzsperren beim Einsatz von SQL und SQL Programmierung ist mit Commit wesentlich einfacher als ohne. Wenn Programme mit commitlevel *none gewandelt werden, werden bei SQL Operationen ohne cursor Sätze nicht gesperrt, was beim Vergleich record level access mit SQL Probleme schafft. Ersetze ich chain / update durch select into / update, kann der Satz bei der SQL Variante zwischen lesen und update von anderen Benutzern geändert werden, was nicht gewollt sein kann.
Nun gibt es (fast) immer mehrere Wege nach Rom, commit ist hierbei der einfachste!
- Programme mit commitlevel *change (ist eh' default) wandeln, select into mit Sperrlevel repeatable read (kann man beim Statement mit with Klausel angeben), zur Freigabe der Sperre commit. Der gesamte Bereich der vorhandenen Anwendung ist davon nicht betroffen, für alles, was mit RLA gemacht wird, ändert sich nichts.
Was sich ändert ist, dass die betreffenden Dateien journalisiert werden müssen, was ich ohnehin für alle Dateien empfehlen würde - das ist bei jeglicher Fehlersuche Gold wert.

D*B

PS: noch etwas zu meiner "Art": es gibt keine dummen Fragen, sondern nur dumme Antworten, vielleicht sollte ich den Adressaten kritisch scharfer Antworten künftig deutlicher benennen. In dem Sinne entschudige ich mich bei dibe.