dyn. SQL CRTSQLRPGI-Error

[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.

[B.Hauser]

Eigentlich liegt das nur daran, dass in der SQL-Programmierung eine bestimmte Reihenfolge eingehalten werden muss!

In der Declare-Section werden die Variablen und anschließend die Cursor definiert. Erst anschließend folgt der auszuführende Code. Das Set Option - Statement wird noch vor der Declare Section angegeben. Auch bei der Programmierung wird eine Quelle (allerdings in C!) erstellt.
... und genau in dieser Reihenfolge werden die SQL-Statements vom Precompiler (gleiches Programm für ALLE!) analysiert und Abweichungen mit Warnungen oder Abbrüchen quittiert.

Birgitta