... ich erkenne zwar nicht welcher Aussage du da widersprechen willst, bei commit in Procedures sind schon ein paar Dinge zu beachten:
- Commit/Rollback ist eine Eigenschaft einer Connection bzw. der Activationgroup und wenn eine Procedure innerhalb einer gesicherten Transaktion aufgerufen wird und dann ein Commit oder Rollback absetzt, dann hat das Nebeneffekte für die offene Transaktion.
- gegen den Oops Nerv spricht hier in aller erster Linie die mangelnde Dokumentiertheit und daraus resultierende fehlende Reproduzierbarkeit. Gerade Abläufe wie hier riechen förmlich danach (so kann es für ein CREATE PROCEDURE wichtig sein, ob bei der Erstellung Commit aktiv ist, oder nicht).

D*B

Zitat Zitat von UFK Beitrag anzeigen
Der OpsNav war zwar recht fehleranfällig(und ist es vermutlich immer noch), aber zum Testen eigentlich klasse. Ich hab viele Scripts geschrieben, um Stored Procedures und Functions erstmal damit zu testen, mit gutem Erfolg. Sowohl einige positive als auch (mehr) negative Tests.

Außerdem möchte ich der Aussage mit dem Commitment-Control auch widersprechen. Bei größeren Stored-Procedures habe ich doch auch ROLLBACK verwendet, um letztendlich scheiternde Transaktionen ohne Würgen wieder glatt zu stellen, und das Verhalten in jeder Hinsicht getestet. Natürlich setzt man dann entsprechende Returncodes, damit z.B. Java-Programme mitbekommen, daß die Verarbeitung gescheitert ist.

PS: Benutzt Du eigentlich ATOMIC ?