dyn. SQL CRTSQLRPGI-Error

[edi_box]

Wir haben mehrere dyn. SQLRGPLE-Programme die sich auf einer AS400 mit V5R3M0 Fehlerfrei erstellen lassen.

Wenn man das gleiche Programm auf der zweiten AS400 auch mit V5R3M0 umwandeln will, kommt immer der SQL-Fehler

"SQL0504 Cursor nicht deklariert"

Hat jemand ein Ahnung an was das liegen kann?

hier der Code:

c/exec sql
c+ prepare sql_src from :#sql
c/end-exec

c/exec sql
c+ declare sql_cursor cursor for sql_src
c/end-exec

c/exec sql
c+ open sql_cursor
c/end-exec

c/exec sql
c+ fetch next from sql_cursor into :hf_MANDAD, :hf_KDNRAD
c/end-exec

c/exec sql
c+ close sql_cursor
c/end-exec

hier die Fehlermeldung

SQL0504 .... Cursor sql_cursor nicht definiert (open stmt)
SQL0504 .... Cursor sql_cursor nicht definiert (fetch stmt)
SQL0504 .... Cursor sql_cursor nicht definiert (close stmt)


Danke im Voraus für Euere Hilfe

[Fuerchau]

Da kann man nur raten:
Die Verwendung von Sonderzeichen im Quelltext kann immer problematisch sein, insbesonders wenn die System-CCSID's ggf. abweichen.

Benenne die Variable "#sql" in "sql" um.

Das "#"-Zeichen hat je nach CCSID einen anderen Code und der Compiler kann damit Probleme haben.

[edi_box]

das war es leider nicht, auch mit variablen-Name "sql" geht es nicht

[Fuerchau]

Da das wohl nur ein Auszug der Quelle ist, bist du sicher, dass der Cursor wirklich am Anfang der Quelle deklariert ist ?

Je nach PTF-Stand kann es ggf. verschärfte Restriktionen geben.

[edi_box]

Auf die Anregung mit dem #SQL habe ich mal verschiedenes ausprobiert und bin dabei auf die Lösung gestoßen.

den Prepare, Declare und Open haben wir in ein Subroutine, ebenso den Close und den Fetch in einer eigenen Subroutine.

ich habe die Reihenfolge der SR getauscht, so dass die SR mit dem Declare als erstes im Code steht und erst danach die SR mit Fetch und Close. Prompt lässt sich das Programm erfolgreich umwandeln.

Vielen Dank an Alle die sich den Kopf zerbrochen haben.

[BenderD]

wenn du schon dabei bist:
- laut sql reference dürfen Namen nicht mit SQL anfangen
- Variablennamen müssen im Quelltext (nicht im Scope!!!) eindeutig sein

ich mache seit Jahren:
alle SQL Variablen am Anfang global deklarieren
alle eds mit prefix ibmxx (sowas nimmt sonst keiner)
keine Features bei der Deklaration verwenden, die erst nach V3 gekommen sind, dann klappt es nach allen PTFs und Release Wechseln

D*B

Auf die Anregung mit dem #SQL habe ich mal verschiedenes ausprobiert und bin dabei auf die Lösung gestoßen.

den Prepare, Declare und Open haben wir in ein Subroutine, ebenso den Close und den Fetch in einer eigenen Subroutine.

ich habe die Reihenfolge der SR getauscht, so dass die SR mit dem Declare als erstes im Code steht und erst danach die SR mit Fetch und Close. Prompt lässt sich das Programm erfolgreich umwandeln.

Vielen Dank an Alle die sich den Kopf zerbrochen haben.

[Fuerchau]

Ab V6R1 soll SQL auch mit lokalen Variablen zurechtkommen (in der Prozedur).

[BenderD]

Vorsicht: die Prüfung auf eindeutige Namen innerhalb des Moduls ist in den letzten Releases und PTFs gleichwohl eher geschärft worden.

Ab V6R1 soll SQL auch mit lokalen Variablen zurechtkommen (in der Prozedur).

[B.Hauser]

... noch eine Anmerkung zum Variablen Scope:
1. Vor Release V5R3
In der Dokumentation war beschrieben, dass Host-Variablen nur einmalig in der Quelle definiert sein dürfen. Geprüft wurde das allerdings nicht.
2. Release V5R3
Die Eindeutigkeit der Host-Variablen wurde geprüft und falls die gleiche Variable mehrfach definiert war (lokal in mehreren Prozeduren) wurde die Compilierung mit einem Fehler Level 30 abgebrochen.
3. Release V5R4
Wurde die gleiche Variable mehrfach mit dem gleichen Datentyp und der gleichen Länge definiert, wurde lediglich eine Warnung mit Level 10 ausgegeben
Wurde die gleiche Variable mehrfach mit compatiblem Datentyp oder unterschiedlicher Länge definiert, wurde ein Fehler mit Level 20 ausgegeben
Wurde die gleiche Variable mehrfach mit unterschiedlichen Datentypen definiert, wurde ein Fehler mit Level 30 ausgegeben.
4. Release 6.1
Die gleiche Variable kann mehrfach mit unterschiedlicher Definition und verschiedenen Prozeduren definiert werden ohne eine Fehlermeldung zu prodzieren.

Was die Namensgebung angeht.
Wie Dieter bereits erwähnt hat, sollte keine Variable, Datenstruktur oder Cursor, die mit embedded SQL verwendet werden mit SQL oder SQ beginnen. Der Precompiler generiert zusätzliche Variablen, die mit diesen Buchstaben beginnen und IBM behält sich vor in Zukunft weitere benötigte Variablen mit dieser Namensgebung zu benennen.
Selbst wenn es heute keine Probleme gibt mit SQL+Irgendwas, könnte IBM in einem folgenden Release eine Hilfsvariable definieren und verwenden, die genau SQL+Irgendwas entspricht. Im besten Fall lassen sich die Programme dann nicht mehr Compilieren im schlimmsten Fall wird irgendwas zerschossen. Um diesen Problemen vorzubeugen, sollte man auf das vorangestellte SQL im Namen verzichten.

... und auch das ist irgendwo in der SQL Referenz oder Embedded SQL Programmierung beschrieben:
Das DECLARE-Statement muss in der Quelle physisch immer vor der OPEN-Anweisung stehen. (In welcher Reihenfolge dies ausgeführt wird ist unerheblich).

Birgitta

[Fuerchau]

Ein DECLARE wird nicht ausgeführt.
Man kann das auch in der Compilerliste sehen.
Die Definition wird lediglich in das SQLPKG übernommen.
Der Compiler benötigt dies für die Referenz der Statements.

[Pikachu]

Ein DECLARE wird nicht ausgeführt.
Man kann das auch in der Compilerliste sehen.
Die Definition wird lediglich in das SQLPKG übernommen.
Der Compiler benötigt dies für die Referenz der Statements.

Dann ist das anscheinend so wie bei PLIST und KLIST, wobei die allerdings auch ganz an Ende des Programms stehen können?

[Fuerchau]

Wie Radio Eriwan: im Prinzip ja, aber ...

RPG/LE ist ein Mehrphasen-Compiler, der halt Syntax prüft, Referenzen aufbaut und dann erst das Programm erstellt.

SQL wird als Pre-Compiler aufgerufen, generiert eine neue Quelle und hat nur 1 Phase, deshalb ist die Reihenfolge wichtig.
Als Hostvariablen können ja alle Programmvariablen verwendet werden. Allerdings erkennt der Precompiler auch hier keine Variablen, die nach ihrer Verwendung definiert werden.