Erst mal vielen Dank für die Antworten.
@Ralf: Das Programm ist nicht von mir, aber ich habe es vor einigen Jahren von der externen Beraterfirma, die es einst programmiert hat, geerbt und betreue es seitdem. Es berechnet die Datenausgabe an einen externen Lohndatenabrechner. Zu diesem Zweck rennt es durch den ganzen Personalstamm und berechnet für jeden Mitarbeiter die auszugebenden Daten. Dabei muss es Stammdaten, Zahlungsdaten, Abwesenheitsdaten usw. ausgeben mit der Maßgabe, dass nur Daten ausgegeben werden sollen, die sich seit dem letzten Lauf geändert haben, so dass ein umfangreiches Logging der eigenen Ausgabe erforderlich ist. Bei vielen Daten ist dabei noch Detailcoding vorhanden. Das Ganze hat einen erheblichen Komplexitätsgrad.
Der Code war sehr mies strukturiert. Es handelt sich um ein OO-Programm, bei dem das OO darin besteht, dass ein einziges Objekt erzeugt wird und im Constructor der gesamte Nutzcode steht. Anstelle von Formroutinen werden lokale Methoden verwendet. That's OO for you.

Auch sonst fand ich den Code alles andere als dolle, und gerade angesichts der Komplexität des Ganzen ist gute Strukturierung durchaus wichtig. Deswegen habe ich den Code grundlegend überarbeitet, musste dabei aber immer vorsichtig sein, denn es ist aus offensichtlichen Gründen (Gehälter sind in HR das Herzblut) ein sehr kritischer Report, der funktionieren muss, was er inzwischen auch ganz gut tut.
Du wirst lachen: Eine Hintergrundverarbeitung habe ich vor zwei Jahren oder so auch eingebaut, nebst der Möglichkeit, auf die Ergebnisse früherer Programmläufe zuzugreifen und sich die (geloggten) Ergebnisse derselben zu ziehen. Dies ist notwendig, da die Sachbearbeiter das Programm händisch starten und die Ergebnisdateien auf ihre lokalen PCs herunterziehen. Bei einem im Hintergrund, also ohne GUI, laufenden Programm geht das nicht, und meine Lösung besteht halt darin, dass sie nach Ende des Programmlaufs dieses erneut im Vordergrund starten und dann das zuvor berechnete Ergebnis herunterladen können. Hat nebenbei auch den Vorteil, dass bei ihnen nicht ewig ein SAPGui-Modus blockiert ist und sie nicht von vorne rechnen müssen, wenn mal nach erfolgten Berechnungen die Datenübertragung von Server zu SAPGui auf die Nase fällt (das hatten wir früher alles).
Über den ganzen Prozess kann man sicherlich diskutieren, aber: Never change a running system.
Die Ausführung im Vordergrund hat allerdings den Charme, dass man hinterher nicht nur csv-Dateien hat, die man sich in Excel zurechtformatieren kann, sondern auch komfortabel zwischen mehreren ALVs (einem pro Ergebnisdatei; es entstehen immer mehrere) blättern und die Daten darin durchsehen kann. Für Testläufe, also solche ohne Datenausgabe und Logging, ist dies sehr attraktiv, und im Personalwesen braucht man eigentlich immer Testläufe vor jeder Abrechnung, weil es immer irgendwelche fehlerhaften Personaldaten gibt, die man glattziehen muss, bevor man das wirklich in die Abrechnung gibt.
Um dies grundsätzlich möglich zu machen, habe ich gesagt, dann soll er im Testlauf halt regelmäßig einen COMMIT WORK machen. Da der Testlauf nichts macht, macht auch der COMMIT WORK nichts. Wir haben genug Serverleistung, und dann können die Sachbearbeiter nach einer Stunde oder wie lange das Ding läuft ihr Ergebnis anschauen. Die produktiven Daten rechnen sie dann über Nacht im Hintergrund (da will ich keine Zwischen-COMMITs haben, denn falls während des Programmlaufs irgendwas schiefgeht - und sei es, dass der Server mal abschmiert - will ich keine halb berechneten Lohnausgaben haben, da man die nie vernünftig ergänzt bekommt).
Nun musste ich aber feststellen, dass auch im Testlauf bestimmte Logänderungen vorgenommen werden, so dass Testläufe nachfolgende Produktivläufe verfälschen. Dies programmtechnisch zu ändern wäre nicht trivial, und die Gefahr wäre groß, dass ich mir bei den entsprechenden Umbauten neue Bugs einfange, die ich in diesem Programm aus offensichtlichen Gründen so gut wie möglich vermeiden möchte. Da war meine Idee, ob man das nicht einfach lösen kann, indem ich statt regelmäßiger COMMIT WORKs einfach regelmäßige ROLLBACK WORKs mache. Im Testlauf soll sich auf der Datenbank ja nichts verändern.
Mittlerweile kann ich sagen, dass ROLLBACK WORK den Timeout nicht zurücksetzt. So einfach geht es also nicht. Was ich aber jetzt im Testlauf mache, ist ein ROLLBACK WORK und gleich danach ein COMMIT WORK. Das funktioniert natürlich.
Also soweit ich das diesem Thread entnehme, ging das allenfalls bis Release 7.00 und ist insofern heute keine Option mehr.
larsi hat geschrieben:Ich habe mir bislang immer mit der Klasse CL_SWF_UTL_TIMEOUT_SERVICE beholfen - die erreicht das nämlich ohne Verwendung von COMMIT WORK oder ROLLBACK.
Also wenn ich mir diese Klasse so in der SE24 anschaue, dann kann ich das kaum glauben. Die kann man ja mit einem Blick überschauen; die besteht ja nur aus wenigen Methoden, die jeweils nur wenige Befehle enthalten. Diese Befehle kommen mir zudem noch recht sinnlos vor
(vor allem die Methode ON_TIMEOUT), aber gut, die Klasse ist nicht dokumentiert; ihr Autor wird sich schon was dabei gedacht haben.