View Full Version : RPGfehler sql0312
Hallo beieinander,
möchte ein Programm auf 2 verschiedenen iSeries umwandeln. Auf einem System funktioniert das einwandfrei und auf dem 2. System kommt der Precompiler-Fehler SQL0312.
Auf beiden Systemen ist Release V5R4M0 installiert.
auf dem 1. System (mit korrekter Umwandlung) ist PTF-Stand SF99540 Level 7107 Kum-Tap C7107540 installiert
auf dem 2. System (mit Umwandlungsfehler) ist PTF-Stand SF99540 Level 8305 Kum-Tap C8305540 installiert.
Auszug aus dem Programmcode:
d ##drbtr s like(drbtr)
d ##drkdnr s like(drkdnr)
c eval ##drbtr1 = drbtr
c eval ##drkdnr = dridnr
c/exec sql
+ select dafbtr,
+ dakddb,
+ dargnr,
+ sum(daliwt)
+ into :##drbtr,
+ :##drkdnr,
+ :##drrgnr,
+ :daliwt
+ from lired
+ where dafbtr = :##drbtr
+ and dakddb = :##drkdnr
+ and dargnr = :##drrgnr
+ and dakanr <> 'NEUDISPO'
+ group by dafbtr,
+ dakddb,
+ dargnr
+ order by dafbtr,
+ dakddb,
+ dargnr
c/end-exec
SQL0312 30 1283 Position 20 Variable ##DRBTR nicht definiert oder nicht verwendbar. SQL0312 30 1284 Position 20 Variable ##DRKDNR nicht definiert oder nicht verwendbar.
Hat jemand ne Ahnung an was das liegen könnte?
Da stellt sich mir die Frage der CCSID.
Das #-Zeichen ist nicht CCSID-Neutral und kann daher je nach Job/Source-CCSID falsch interpretiert werden.
Versuche, Sonderzeichen in Namen zu vermeiden.
aus Vorumwandlungsliste entnommene CCSID's
System mit funktionierender Umwandlung:
CCSID der Quellendatei....273
CCSID des Jobs............65535
System mit falscher Umwandlung:
CCSID der Quellendatei....273
CCSID des Jobs............65535
Die CCSID's sind gleich
Habe aber trotzdem Deinem Ratschlag zufolge die Namen abgeändert auf yxbtr und yxkdnr.
Es kommt der gleiche Fehler.
Hm, da ist mal wieder raten angesagt.
Da du die Felder mit LIKE definierst, bist du sicher, dass die Quelldefinition der Felder identisch ist ?
sind die Variablen mehrfach (mit unterschiedlichem Scope) definiert? da verhält sich der Compiler in unterschiedlichen Release und PTF Ständen unterschiedlich (richtig ist dabei, dass das laut Reference nicht geht, ging aber früher!)
D*B
Hallo beieinander,
möchte ein Programm auf 2 verschiedenen iSeries umwandeln. Auf einem System funktioniert das einwandfrei und auf dem 2. System kommt der Precompiler-Fehler SQL0312.
Auf beiden Systemen ist Release V5R4M0 installiert.
auf dem 1. System (mit korrekter Umwandlung) ist PTF-Stand SF99540 Level 7107 Kum-Tap C7107540 installiert
auf dem 2. System (mit Umwandlungsfehler) ist PTF-Stand SF99540 Level 8305 Kum-Tap C8305540 installiert.
Auszug aus dem Programmcode:
d ##drbtr s like(drbtr)
d ##drkdnr s like(drkdnr)
c eval ##drbtr1 = drbtr
c eval ##drkdnr = dridnr
c/exec sql
+ select dafbtr,
+ dakddb,
+ dargnr,
+ sum(daliwt)
+ into :##drbtr,
+ :##drkdnr,
+ :##drrgnr,
+ :daliwt
+ from lired
+ where dafbtr = :##drbtr
+ and dakddb = :##drkdnr
+ and dargnr = :##drrgnr
+ and dakanr <> 'NEUDISPO'
+ group by dafbtr,
+ dakddb,
+ dargnr
+ order by dafbtr,
+ dakddb,
+ dargnr
c/end-exec
SQL0312 30 1283 Position 20 Variable ##DRBTR nicht definiert oder nicht verwendbar. SQL0312 30 1284 Position 20 Variable ##DRKDNR nicht definiert oder nicht verwendbar.
Hat jemand ne Ahnung an was das liegen könnte?
Datei mit der Felddefinition DRBTR
DRBTR CHAR 3 3 31 Beides Betrieb
Feldtext . . . . . . . . . . . . . . . : Betrieb
Referenzinformationen
Referenzdatei . . . . . . . . . . . . . : BUG§DREF
Bibliothek . . . . . . . . . . . . . : BUPBRAV01
Referenzsatzformat . . . . . . . . . . : BUG§DFREF
Referenzfeld . . . . . . . . . . . . . : §§BTR
Geänderte Attribute . . . . . . . . . . : Keine
ID des codierten Zeichensatzes . . . . . : 273
Daten Feld- Puffer Puffer Feld Spalten
Feld Art Länge Länge Position Verwend. Überschrift
Datei im SQL
Feld Art Länge Länge Position Verwend. Überschrift
DABTR CHAR 3 3 1 Beides Firma
Feldtext . . . . . . . . . . . . . . . : Betrieb
Referenzinformationen
Referenzdatei . . . . . . . . . . . . . : BUG§DREF
Bibliothek . . . . . . . . . . . . . : BUPBRA
Referenzsatzformat . . . . . . . . . . : BUG§DFREF
Referenzfeld . . . . . . . . . . . . . : §§BTR
Geänderte Attribute . . . . . . . . . . : Keine
ID des codierten Zeichensatzes . . . . . : 273
Ich hab jetzt mal nur 1 Feld geprüft. Das ist aber gleich
Hallo,
wie die Vorredner gesagt haben. Ab bestimmten Versionen
läßt der Compiler keine Merfachdefinitionen im SQL zu.
Prüfe bitte mal genau auf welche Referenzen die Felder
drbtr und drkdnr sich beziehen könnten.
Wenn zwei oder mehr Definitionen vorhanden sind
( selbst bei gleicher Feldlänge und Feldart )
kann der Compiler die Felder nicht mehr auflösen.
Also müssen die Felder eindeutig definiert werden.
d ##drbtr s like(drbtr)
d ##drkdnr s like(drkdnr)
Gruß
Michael
Hallo,
andere Vermutungen:
1. Wo sind die Referenz-Felder definiert?
In einer Datei, die in den F-Bestimmungen angegeben wurde? Wenn ja ist die Datei zum Compilierungszeitpunkt in der Bibliotheksliste vorhanden?
In einer (verschachtelten) Copy-Strecke? (aus solche Felder kann der SQL-PreCompiler u.U. nicht zugreifen.
2. Vielleicht stört sich der Precompiler daran, dass die gleichen ##-Variablen einmal als Ausgabe-Felder (into ...) und zum anderen in der Where-Anweisung verwendet werden.
Ich würde die Variablen nicht als Ausgabe-Variablen verwenden, das die Werte ja bereits gesetzt sind und durch die Where-Anweisung nur erneut ausgegeben werden.Dadurch wird das ganze SQL-Statement auch wesentlich kürzer, d.h. Group By und Order By entfallen.
c/exec sql
C+ select sum(daliwt) into :daliwt
C+ from lired
C+ where dafbtr = :##drbtr
C+ and dakddb = :##drkdnr
C+ and dargnr = :##drrgnr
C+ and dakanr <> 'NEUDISPO'
C/end exec
Übrigens: Unter Release V5R4 können die gleichen Variablen mit der gleichen Definition problemlos in diversen Sub-Prozeduren definiert werden. (Vor Release V5R3 wurde eine Mehrfach-Definition der gleichen Variablen nicht geprüft. Unter Release V5R3 wurde ein Compilierungs-Fehler mit Level 30 ausgegeben. Ab 6.1. können Variablen vom PreCompiler den Prozeduren zugeordnet werden.)
Birgitta
Hallo MK,
Deine Aussage kann ich jetzt nur noch bestätigen. Habe das Programm jetzt unter Release 6.0 compiliert. Funktioniert auch da nicht.
Leider kann ich nicht mehr nachvollziehen, ob das Programm bereits bei der Konvertierung auf die Nase fällt, da zu diesem Zeitpunkt die betreffende Änderung noch nicht implementiert war.
Habe jetzt Programmversionen getestet, die sich umwandeln ließen:
1. explizite Vorgabe der Feldattribute
Aber das ist ja eh klar
2. mit like definiert, aber als Basisfeld
das Datenbankfeld aus der SQL-Datei.
Die aktuelle Definition sieht jetzt so aus:
d ##drbtr s like(dabtr)
d ##drkdnr s like(dakddb)
Mein Resümee daraus ist, dass nur bei Verwendung von Feldern aus externen Datenstrukturen (in der LIKE Definition) einen Fehler verursachen.
Danke an alle für die schnelle Hilfe. Das Programm lässt sich nach meiner Anpassung auf allen Rechnern kompilieren
Hallo,
andere Vermutungen:
1. Wo sind die Referenz-Felder definiert?
In einer Datei, die in den F-Bestimmungen angegeben wurde? Wenn ja ist die Datei zum Compilierungszeitpunkt in der Bibliotheksliste vorhanden?
In einer (verschachtelten) Copy-Strecke? (aus solche Felder kann der SQL-PreCompiler u.U. nicht zugreifen.
2. Vielleicht stört sich der Precompiler daran, dass die gleichen ##-Variablen einmal als Ausgabe-Felder (into ...) und zum anderen in der Where-Anweisung verwendet werden.
Ich würde die Variablen nicht als Ausgabe-Variablen verwenden, das die Werte ja bereits gesetzt sind und durch die Where-Anweisung nur erneut ausgegeben werden.Dadurch wird das ganze SQL-Statement auch wesentlich kürzer, d.h. Group By und Order By entfallen.
c/exec sql
C+ select sum(daliwt) into :daliwt
C+ from lired
C+ where dafbtr = :##drbtr
C+ and dakddb = :##drkdnr
C+ and dargnr = :##drrgnr
C+ and dakanr <> 'NEUDISPO'
C/end exec
Übrigens: Unter Release V5R4 können die gleichen Variablen mit der gleichen Definition problemlos in diversen Sub-Prozeduren definiert werden. (Vor Release V5R3 wurde eine Mehrfach-Definition der gleichen Variablen nicht geprüft. Unter Release V5R3 wurde ein Compilierungs-Fehler mit Level 30 ausgegeben. Ab 6.1. können Variablen vom PreCompiler den Prozeduren zugeordnet werden.)
Birgitta
Mit dem Verkürzen hast Du natürlich recht. Ich vermute sogar, dass das einen Performance-Vorteil bringt. Werde Deinen Optimierungsvorschlag so übernehmen.
Gruß Peter