embedded SQL - close cursor

[Armin]

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!

[malzusrex]

Also ich bin jetzt nicht der SQLRPGLE-Spezi, aber bei mir hat beim umwandeln die angabe CloSqlCsr(*ENDMOD) geholfen.

gruß ronald

[JonnyRico]

Jo,

oder das Programm in einer eigenen Activisiongroup laufen lassen.

[Fuerchau]

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

[Armin]

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?

[JonnyRico]

das Datum hat nichts mit dem Cursor zu tun. Sind das denn immer andere Select-Statements die du da verarbeitest???

[Armin]

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.

[Fuerchau]

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.

[Armin]

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.

[B.Hauser]

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

[BenderD]

Hallo,

hier muss man Cursor und ODP auseinanderhalten.
Im Programm habe ich einen Cursor, dessen öffnen zur neu Psoitionierung führt und desse Status nur zwichenn open und close wechseln kann; alles andere verursacht Fehler.
Die Datenbank kennt einen ODP, den sie besser offen lässt, da er meist nochmal gebraucht wird und der dann Sperren auf die Tables hat.
Das ganze CLOSQLCSR Gedönse wirkt auf Cursor und nicht auf ODPs, auch wenn es zuweilen anders ausschauen mag!
ODPs, die keiner benutzt, werden von SQL automatisch geräumt, wenn sie von SQL benötigt werden. Dasselbe erreicht man auch mit ALCOBJ CONFLICT(*RQSRLS) wenn einen das irgendwann mal stört.

@Birgitta:
Mit dem neu eröffnen von ODPS in laufenden Programmen habe ich unter V5R3 schon positive Überraschungen erlebt (nach anlegen eines Index)
Wenn Daten komplett über einen Zugriffspfad geholt werden können, dann ist meist mit dem Design was faul, ausser bei Where in Subselect Konstrukten, wo select * eh' nicht geht.

mfg

Dieter Bender

[Armin]

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.

Deinen Vorschlag auf statisches SQL zurückzugreifen hab ich versucht:
declare Filecursor cursor for Filesection
open Filecursor
SQLCOD = -514 (kein prepaire durchgeführt) !?

Andere Frage noch:
In der SELECT-Anweisung wurden 2 Tabellen mit LEFT JOIN verbunden.
Jedes Dateifeld einzeln anzusprechen find ich bei großem Umfang nervig. Deshalt "*" und INTO in die externe DS, die ich mit der DDS beschrieben habe. Was aber wenn ich nun 2 Tabellen anspreche?