Implicit close bei non scrollable cursor
- Dieses Thema hat 6 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 18 Jahre, 4 Monaten vonTeilnehmer.
- AuthorPosts
- 10. Dezember 2004 um 8:50 Uhr #2484
Hi folks,
ich habe folgendes Problem:
Ich habe einen Non Scrollable CURSOR mit FOR FETCH ONLY ohne WITH HOLD.
Vor dem OPEN wird ein CONNECT auf ein Remote-System durchgeführt.
Die FOR FETCH ONLY-Option habe ich extra eingebaut, damit DB2 Block fetch nutzen kann.
Bei dem zugehörigen CLOSE CURSOR erhalte ich nun – nach Einbau von FOR FETCH ONLY- einen -501  :-[, obwohl der letzte SQL-Befehl direkt vor dem CLOSE ein FETCH mit einem "normalen" (nicht negativen) SQLCODE +100 ist .
Heisst das, dass DB2 in dieser Konstellation einen implicit close durchführt?
Nach Ausbau von FOR FETCH ONLY funktioniert der CLOSE CURSOR wieder.
Wenn ja, hiesse das ja, ich könnte bei einem CLOSE CURSOR ja nicht mehr vernüftig auf einen -501 reagieren, denn er kann ja dann auch bei ordnungsgemäßem Ablauf auftreten, oder?
Weiss jemand was darüber?
Gruss Peter
28. Dezember 2004 um 16:50 Uhr #2949Hi Peter,
hier ein Hinweis – lieber spät als nie ;):
Check for a previous SQL return code that may have
closed the cursor. Commit and rollback operations close cursors. SQLCODES -404, -652, -679, -802, -901, -904, -909, -910, -911, and -913 will force the cursor to close. After the cursor is closed, any fetches or close cursor statements will receive this SQLCODE -501.If no previous SQL return codes have been issued, correct the logic of the application program to ensure that the cursor is open at the time the FETCH or CLOSE statement is executed.
Ciao
Gernot10. Januar 2005 um 7:42 Uhr #3277Hallo Gernot,
die Broschüre habe ich natürlich auch gelesen …….
Peter
10. Januar 2005 um 17:17 Uhr #3491Hi Peter,
wenn Du einen CONNECT ausführst, solltest Du auch einen DISCONNECT ausführen. Dann ist aber eine CLOSE nicht erforderlich, da er vom DISCONNECT implizit durchgeführt wird:
Using DISCONNECT is optional. Without it, DB2 performs the same functions when the task terminates. (The function is an implicit DISCONNECT.) If the objective is to shut down your application, you can improve shut down performance if you request DISCONNECT explicitly before the task terminates.
If an OPEN is in effect when the DISCONNECT is issued (that is, a plan is allocated), CAF issues an implicit CLOSE with the SYNC parameter.
Gruß
GernotPS: Die Anwort mag Dir trivial erscheinen, Â :-/ sorry, ich versuche mir nur einen Reim aus den wenigen Informationen zu machen.
12. Januar 2005 um 9:45 Uhr #3634Hallo Gernot,
danke für die Informationen. 🙂
Das Problem hat sich bei uns jetzt folgendermassen geklärt: Das Programm führte intern SET CURRENT PACKAGESET-Befehle aus um über diese Technik Parallel-Verarbeitung zu realisieren (mehrere Instanzen des Programms über unterschiedliche Collections/CREATOR)
Irgendwann hat sich das Programm so verlaufen, dass es einen Cursor CLOSEN wollte in einer anderen COLLECTION als der, in der es den CURSOR geöffnet hatte. Das ging natürlich nicht.
Aber vielen Dank nochmal für Deine Unterstützung.
GRuss Peter
PS: Gibt es im Z/OS – Umfeld einen DISCONNECT? Ist mir bislang noch gar nicht begegnet. ???
12. Januar 2005 um 12:05 Uhr #3740DISCONNECT gibt es, wenn die Verbindung von z/OS zu DB2 mittels CAF erfolgt. Dann kann mit CALL DSNALI(‚DISCONNECT Â ‚); das DB2 "abgekoppelt" werden.
Verbindungen von DB2 zu DB2 müssen über CONNECT RESET bzw. RELEASE connection abgebaut werden.
12. Januar 2005 um 12:09 Uhr #3809Hallo Ulrich!
danke für die Info! 🙂 🙂
Gruss Peter - AuthorPosts
You must be logged in to reply to this topic.
