View Full Version : embedded SQL - close cursor
Hallo zusammen.
Ich mache meine ersten Gehversuche mit SQL im RPG.
Funktioniert so weit so gut. In einer FOR-Schleife krieg ich aber den Cursor nicht mehr zu.
For i=1 to n
Fileselect = 'select * from ......'
prepare Filesection from :Fileselect
declare Filecursor cursor for Filesection
open Filecursor using: Variable
Dou SQLCOD = 100
Fetch next from Filecursor into :File_ds
If SQLCOD <> 100
Verarbeitung
endif
close Filecursor
endfor
Wenn ich das PGM beende habe ich das File noch offen - HILFE!
Also ich bin jetzt nicht der SQLRPGLE-Spezi, aber bei mir hat beim umwandeln die angabe CloSqlCsr(*ENDMOD) geholfen.
gruß ronald
Jo,
oder das Programm in einer eigenen Activisiongroup laufen lassen.
c/exec sql
c+ set option closqlcsr=*endmod
c/end-exec
neben weiteren Optionen wie:
commit=*none -- wenn ohne Transaktionen gearbeitet wird
datfmt=*iso -- um sicherzustellen, das Datum-Felder 10-stellig verwendet werden
c/exec sql
c+ set option closqlcsr=*endmod
c/end-exec
neben weiteren Optionen wie:
commit=*none -- wenn ohne Transaktionen gearbeitet wird
datfmt=*iso -- um sicherzustellen, das Datum-Felder 10-stellig verwendet werden
Super, das war´s. Viiiiielen Dank!
Verstehen tu ich´s aber nicht. Im 1. Schleifendurchlauf schließt der close und im 2. nicht mehr. Und was hat das ganze mit einem Datum zu tun?
das Datum hat nichts mit dem Cursor zu tun. Sind das denn immer andere Select-Statements die du da verarbeitest???
das Datum hat nichts mit dem Cursor zu tun. Sind das denn immer andere Select-Statements die du da verarbeitest???Nein! "select * from FILE where ALPHAFELD=?"
In den Schleifendurchläufen wird jeweils ein anderer Inhalt dieses Feldes abgefragt.
Dass der Cursor offen bleibt, hat intern was mit Optimierungen zu tun.
Du kannst deine SQL's beschleunigen wenn du statische SQL's verwendest:
declare Filecursor cursor for
select * from FILE where ALPHAFELD=:MYFIELD
MYFIELD wird einfach als RPG-Feld definiert.
Damit sparst du dir den Prepare.
Besten Dank.
Dann will ich euch mal nicht weiter aufhalten. Den Tipp mit dem statischen SQL und dem variablen Inhalt wird ich im nächsten Teil testen.
Im 1. Schleifendurchlauf schließt der close und im 2. nicht mehr. Und was hat das ganze mit einem Datum zu tun?
Beim ersten Durchlauf wird der Cursor in der Regel vom System geschlossen, da der Query Optimizer mindestens 2 Durchläufe benötigt um sich auf einen Zugriffs-Pfad festzulegen.
Wenn der ODP (offener Zugriffs-Pfad) nicht geschlossen wird, was durch CLSSQLCSR = *ENDMOD am Ende des Moduls erfolgt. Wird der Optimizer bei jedem Durchlauf einen optimalen Zugriffs-Weg aus allen vorhanden Indices und geschlüsselten logischen Dateien ermitteln. Ist ein Zugriffs-Pfad bereits geöffnet entfällt dieser Overhead. Dies ist vorallem bei komplexen SQL-Statements von Vorteil.
Allerdings ... bleibt der Zugriffspfad geöffnet und verändern sich die Daten so sehr, dass eigentlich ein anderer Zugriffs-Pfad optimaler wäre, erfolgt KEINE Neu-Ermittlung! Da hilft dann nur die Aktivierungs-Gruppe zu schließen, den Job zu beenden oder grundsätzlich mit CLSSQLCSR zu arbeiten.
... Und übrigens sollte man nicht SELECT * verwenden, sondern die Felder, die man benötigt gezielt auswählen. Daduch können mit einem Block mehr Daten eingelesen werden. Zum anderen kann der Optimizer einen Zugriffs-Pfad ermitteln, der einen Index ONLY-Access ermöglicht, d.h. alle benötigten Informationen sind bereits in den Schlüssel-Werten hinterlegt und ein zusätzlicher Zugriff auf den Datensatz ist nicht erforderlich.
Birgitta