SQL - Fehler

[Kaufmann]

Innerhalb einer Prozedur wird der Fetch einfach nicht ausgeführt.

Prozedur sieht so aus:


C/EXEC SQL
C+ DECLARE C1 CURSOR FOR
C+ SELECT * FROM SCHUELLER/ARBP2P
C+ WHERE FERT1B BETWEEN 680 AND 699 AND BLOCKN <> 0
C+ ORDER BY MDT, BLOCKN, FERT1B, LFDNREH, STKZ2B,
C+ CASE RLB WHEN 'R' THEN '1' WHEN ' ' THEN '2' WHEN 'L' THEN '3' END
C+ FOR UPDATE OF BLFOLGE
C/END-EXEC

C/EXEC SQL
C+ OPEN C1 USING :g_dsARBP2P
C/END-EXEC

C/EXEC SQL WHENEVER NOT FOUND GO TO ENDE1
C/END-EXEC

C*-----------------------------
C SQLCOD DOUNE 100
C*-----------------------------
C/EXEC SQL
C+ FETCH NEXT FROM C1 INTO :g_dsARBP2P
C/END-EXEC
C*-----------------------------

// Ermittlung von BLFOLGE in Free-RPG

C/EXEC SQL
C+ UPDATE SCHUELLER/ARBP2P
C+ SET BLFOLGE = :g_dsARBP2P.BLFOLGE
C+ WHERE CURRENT OF C1
C/END-EXEC

C*-----------------------------
C ENDDO

wenn ich debuge dann steht im Wert SQLCOD = -000000501(beim zweiten Schleifendurchgang) und in der Strukur in die ich schreiben will steht nichts

g_dsARBP2P = def. wie Satz in Datei und global.

Was kann ich tun?
Mache ich etwas falsch?

[Fuerchau]

Wann schließt du denn den Cursor ?
Was steht im SQLCOD nach dem Open ?

[Kaufmann]

Ich mache den CLOSE ganz am Schluss nach der Schleife

Code:

........ Code der oben steht

C ENDDO

C ENDE1 TAG
C*-----------------------------
C/EXEC SQL CLOSE C1
C/END-EXEC
C*-----------------------------

[mk]

Der Sqlcode 501 sagt
Cursor &1 nicht geöffnet


Also erst den close und dann den Open

Gruss
Michael

[Fuerchau]

C/EXEC SQL
C+ OPEN C1 USING :g_dsARBP2P C/END-EXEC

Da liegt der Hund begraben !

Wofür gibst du da das USING an ?
In deinem SQL gibts keine Parameter und USING muss auf eine SQLDA verweisen, wenn bei dynamischen SQL's "?" verwendet werden.

[B.Hauser]

Nur so eine Frage:

Arbeitet Ihr mit Commitment Steuerung und wird irgendwo ein COMMIT oder ROLLBACK via SQL gesetzt?

Wenn ja werden dadurch alle SQL Cursor geschlossen, es sei den im DECLARE-Statement ist WITH HOLD angegeben.

Birgitta

[Kaufmann]

1. Es wird kein ROLLBACK oder COMMIT verwendet.
2. Ich habe die Zeile auch mit
C/EXEC SQL
C+ OPEN C1
C/END-EXEC

probiert => gleiches Ergebnis

[Fuerchau]

Das Problem ist eigentlich ein ganz anderes:

Positioned UPDATE statements identifying the cursor associated with a select-statement can update all
updateable columns, if:
v The select-statement does not contain one of the following:
– An UPDATE clause
– A FOR READ ONLY clause
– An ORDER BY clause
v The DECLARE CURSOR statement does not contain a SCROLL keyword without the DYNAMIC
keyword.

Ich denke, dass SQL eher hier ein Problem hat und der Folgeaufruf nur ein Folgefehler ist.
Lass das Order-By weg oder verwende einen "Update where".

[pwrdwnsys]

Grundsätzlich bei allen SQL-Problemen: es ist immer das einfachste, den Debugger im Job zu starten und hinterher das Joblog zu betrachten. Steht alles exakt drin. Kann der Debugger nicht direkt gestartet werden, (z.Bsp. wg. Remote SQL) Dann die Abfrageoptionsdatei QAQQINI anpassen und den Parameter "MESSAGES_DEBUG" auf "*YES" setzen. Die QAQQINI muss dabei in der QGPL stehen, die Ursprungsdatei ist in der QSYS. Einfach kopieren.

[Fuerchau]

Achtung: CRTDUPOBJ und nicht CPYF ... CREATE(*YES) !

[Kaufmann]

Der Fehler lag bei der Umwandlung.

Ich habe
CRTSQLRPGI OBJ(SCHUELLERO/NACHT547) SRCFILE(SCHUELLERS/QRPGLESRC)
OBJTYPE(*MODULE) DBGVIEW(*SOURCE)

gemacht.

Mit CRTSQLRPGI OBJ(SCHUELLERO/NACHT547) SRCFILE(SCHUELLERS/QRPGLESRC)
COMMIT(*CHG) OBJTYPE(*MODULE) DBGVIEW(*SOURCE) geht es.

Grund:
Die COMMIT-Steuerung ---> COMMIT(*CHG)

[Fuerchau]

Das kannst du in der Quelle per
c/exec sql set option commit=*chg
c/end-exec
auch machen.
Bist du sicher, dass die Dateien auch im Journal aufgezeichent werden ?
Wenn ja, wird STRCMTCTL vor dem Programm gestartet und wann werden deine Updates COMMITed?

Wenn nein, dann kann mit COMMIT=*NONE das ganze abgeschaltet werden.