Debugging im Produktivmandanten

Da die Konsistenz der Datenbankinhalte im Produktivmandanten immer erhalten bleiben muss, werden an das Debugging im Produktivmandanten besondere Anforderungen gestellt:

• Deshalb darf durch das System kein COMMIT WORK ausgeführt werden. Insbesondere müssen Datenbankänderungen bei einem Programmabbruch zurückgenommen werden können. Um dies zu realisieren, wechselt ein Dialog-Prozess in den Debug-Modus. Damit wird der Prozess für den Benutzer reserviert; ein Prozesswechsel wird somit vermieden. Deshalb wird auch kein COMMIT WORK vom System ausgeführt.

• Damit nicht alle Prozesse durch Debugging-Aufgaben gesperrt werden können, stehen nur die Hälfte aller Dialogprozesse für das Debugging zur Verfügung.

  Achtung

  Da nur eine begrenzte Zahl von Prozessen in den Debug-Modus wechseln können, sollten Sie den Debugger möglichst bald wieder verlassen, da dieser Prozeß sonst von anderen Benutzern nicht verwendet werden kann.

In Testmandanten, wo eine Verletzung der Datenbankkonsistenz keine gravierenden Folgen hat, wird die Anzahl der Prozesse, die in den Debug-Modus wechseln können, durch den Profile-Parameter rdisp/wpdbug_max_no festgelegt. Wenn ein weiterer Benutzer debuggen will und der Prozess deshalb nicht in Debug-Modus wechseln kann, wird für diesen Benutzer nach jedem Debugging-Schritt ein COMMIT WORK abgesetzt und der Prozess wieder für alle anderen Benutzer freigegeben. Daher sind Datenbankänderungen anschließend nicht mehr mit einem ROLLBACK rückgängig zu machen.