... hier muss man fein differenzieren:
bei SQLCLI (und allem, was das benutzt) werden die prepares mit freigegeben.
Datenbanktreiber, die auf meist auf SQLCLI aufsetzen, könnten das aber wieder toppen (indem sie aus dem Commit implizit einen Commit hold machen).

Bei embedded SQL würde ich das für einen Bug halten, rate aber von Stresstests ab.

Die hold klauseln bei declare cursor, commit etc sind DB2 spezifische Erweiterungen, sollte man sich eigentlich eher abgewöhnen. Wobei ich beim Thema ANSI SQL immer mehr Illusionen verliere, je mehr ich mich damit beschäftige und bei der Arbeit an meiner DB2/400 JDBC Bridge für RPG und Co. fällt da einiges an, umso mehr kräuseln meine Nackenhaare, bei DB2/400, aber auch bei Oracle und manchen JDBC Treibern...

D*B

Zitat Zitat von B.Hauser Beitrag anzeigen
Bist Du sicher?
Eigentlich sollten beim Commit oder Rollback lediglich die Cursor geschlossen werden (sofern sie nicht mit WITH HOLD definiert sind).
Beim nächsten Aufruf (mit den gleichen Werten) sollte ein OPEN (ggf. mit anderen Parameter-Marker-Werten) genügen.

Birgitta