RPGfehler sql0312

[buppo]

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?

[Fuerchau]

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.

[buppo]

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.

[Fuerchau]

Hm, da ist mal wieder raten angesagt.
Da du die Felder mit LIKE definierst, bist du sicher, dass die Quelldefinition der Felder identisch ist ?

[buppo]

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

[mk]

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

[B.Hauser]

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

[buppo]

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

[buppo]

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

[BenderD]

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?