RPGfehler sql0312

[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