Mystischer Werteverlust

**prsbrc** · 13-10-15, 10:26

Schönen Vormittag.

Ich stehe, bzw wir stehen hier vor einem Rätsel.

Meiner einer hat hier ein uraltes Printerfile in dem manche Felder namentlich genau gleich heißen wie in der Tabelle. Soweit so gut.

Printerfile:

Code:

A            KNAME1    R        O     3                               
A                                      REFFLD(KKUN/KNAME1 *LIBL/KUNDE)

In meinem Programm (SQLRPGLE 7.2) hole ich mir den gewünschten Satz mittels SQL Select * Into :dsKunde in eine externe Datenstruktur der Tabelle

Code:

D dsKunde       E DS                  EXTNAME( KUNDE )

Jetzt kommt das Seltsame... lt. meinem Verständnis müssten doch jetzt, da die DS weder QUALIFIED noch sonst was ist die Felder im Printerfile befüllt sein aber das ist nicht passiert.

Im Debug sehe ich nach dem Select zB das Feld der DS dsKunde KNAME1 brav befüllt ist jedoch wird dies nicht im Printerfile angedruckt.

Habe mir einen Dump gezogen und hier sieht man das ganze sehr gut das mein Feld KNAME1 2x vorkommt. Einmal leer und einmal befüllt. Somit schaut es für mich so aus als ob der Compiler hier trotzdem einen eigenen Speicher sich holt bzw die DS qualified macht. Dies würde mich dann aber wundern denn der Debugger zeigt mir das Feld mit Wert an (wie weiter unten beschrieben).

Wenn ich das ganze zu einem "native" Chain umbaue dann funktioniert das genze wie gewünscht und im Dump bekomme ich dieses oben erwähnte Feld auch nur einmal.

Jetzt meine Frage... wieso zum "T****" erhalte ich hier durch den Select in eine DS nicht das gleiche Ergebnis wie mit einem Chain auf die Tabelle?
Wieso passiert das? Im Debug mittels EVAL KNAME1 zeigt mir der Debugger brav das Feld mit dem korrekten Wert und nicht *BLANK wie es dann im Printerfile ankommt.
Vieleicht hat ja jemand eine plausible Erklärung denn mit Chain funktioniert das ja ;-)

Ich hoffe ich konnte mein Rätsel halbwegs verständlich schildern ;-)

Grüße!
Christian

**Fuerchau** · 13-10-15, 11:29

KNAME1 2 x im Dump ist schon mal ein Hinweis auf doppelte Definition.
Schau mal im Compile-Spool in der Crossref nach KNAME1 und wo dies(e) definiert wurde(n).
Schau dir die Auflösung des Select/Fetch into an.

**prsbrc** · 13-10-15, 11:39

Hallo Fuerchau.

KNAME1 ist 2x definiert. Einmal in der Tabelle und einmal im Printerfile.
Meine Verwirrung ist nur das es beim Chain mit der F-Definition der Tabelle klappt und mit dem Select in eine E DS der Tabelle ohne F-Definition nicht mehr klappt obwohl die Feldnamen genau gleich heißen bzw gleich definiert sind.

Früher hat man das wohl so gemacht das der Name im PRTF gleich war wie in der PF um sich einen MOVE zu ersparen jedoch funktioniert dieses Prinzip scheinbar nicht mehr wenn man anstatt der "native IO" auf SQL in eine E DS umschwenkt ;-)

**prsbrc** · 13-10-15, 12:08

Wir waren alle Ratlos aber mittlerweile hat sich der Nebel gelöst *gg*
War ein Denkfehler meinerseits denn eine lokale DS in einer Prozedur wiegt halt mehr als die globalen aus dem PRTF :-)

Danke trotzdem!