Stored Procedure & Functions unter Transaktionskontrolle setzen

[Martin82]

Slave.

Welches Proggi würdest du dann für solche Test-Sachen empfehlen?

Habs jetzt mit COMMIT=*ALL probiert. Damit scheints zu klappen!

[BenderD]

... immer das Umfeld, worin es später eingebunden wird.

D*B

Slave.

Welches Proggi würdest du dann für solche Test-Sachen empfehlen?

Habs jetzt mit COMMIT=*ALL probiert. Damit scheints zu klappen!

[UFK]

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 ?

[Martin82]

Bin da ganz bei dir mit deiner Meinung!

Nein, benutze kein ATOMIC!

[BenderD]

... 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

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 ?