Variablenname in Variable

[Fuerchau]

Das Ganze funktioniert nur in RPGLE.
Per Syscolumns kannst du die Feldliste mit Namen und Ausprägung auslesen, allerdings nicht die Pufferposition.
Hier bietet sich DSPFFD mit Outfile an, da bekommt man auch diese.
Per Feldtyp bzw. Spalte STORAGE dann die Bytelänge ermitteln (beachte bei Packed die Länge in Bytes!), ggf. die Feldposition (an Hand von ORDINAL_POSITION) hochzählen.
Bei DATE (4)/TIME (3)/TIMESTAMP (10) hast du jedoch schon verloren, da hier die interne Länge und nicht die Pufferlänge angegeben wird.
Da ist dann DSPFFD wohl besser, da hier das DATFMT berücksichtigt wird.
Bist du so gewappnet kannst du per %SUBST() die Felder vergleichen.
Für die Ausgabe musst du nur noch bei gepackten Feldern ein paar Verrenkungen programmieren.

[BenderD]

... eleganter ist natürlich, wenn man sich das Programm immer dann neu generiert, wenn die Datei sich ändert und dann cached...

[Fuerchau]

War von Eleganz die Rede?
Habe ich da was überlesen?

[holgerscherer]

Die Nummer hatte ich auch mal gemacht zwecks dynamischer Analyse von Dateien und Spiegelung auf eine andere Kiste. War zu V4-Zeiten. Da hat das Blech irgendwann die Weisse Rauchfahne gewunken.

Aber elegant? Das ist was anderes. Vielleicht dynamisch generierter SQL-Code, der dann via RUNSQLSTM aufgerufen wird?

-h

[maro78]

Ich habe das seiner Zeit ohne Pointer und Masochismus einfach mit einem SQL-RPGLE gelöst.

Ob das elegant ist - keine Ahnung. War aber zielführend, nicht teuer, und hatte funktioniert

Für jedes Feld der zu untersuchenden Datei ...

SELECT CAST(COLUMN_TEXT AS CHARACTER (50) ccsid 273),       
 SYSTEM_COLUMN_NAME, 
 SYSTEM_TABLE_NAME 
 FROM QSYS2/SYSCOLUMNS
 WHERE             
 SYSTEM_TABLE_NAME = 'DeineTabelle' AND       
 SYSTEM_TABLE_SCHEMA = 'DeineLib'

... ein SQL-Vergleich auf Feldunterschiede durchführen

SELECT

CASE WHEN
%trim(p$Datei1) + '.' +
%trim(p$Feld) + ' <> ' +   
%trim(p$Datei2) + '.' +      
%trim(p$Feld) + ' THEN ' +
p$Feld                        
ELSE ' ' END            
... n mal für jedes Feld ...

FROM p$Datei1
LEFT OUTER JOIN p$Datei2 ON ...
WHERE ...

... anschließend Fetch into dieses SQL in eine interne DS (hier sqlsatz)

d sqlsatz         ds              
d   sq001                       70
d   sq002                       70
...
d   sq250                       70

d sqlsatzx        ds                          
d   sqxxx                       70    dim(250)

...
c+ FETCH NEXT FROM xyz into :sqlsatz
...
c                   move      sqlsatz       sqlsatzx

Die Felder mit Datenänderung stehen dann als Feldname jeweils in einem Element von sqxxx.
Also alles lesen wo sqxxx(p$Counter) <> *blanks ist und ggf. für die Subfileanzeige mit SQL die Vorher/Nachher Werte dieses speziellen Feldes ermitteln.

[andreaspr@aon.at]

Es gibt auch die Möglichkeit des DESCRIPTOR.
Da kannst du völlig dynamisch dein SQL zusammenbasteln und einlesen.
Das Einlesen einzelner Werte würde wie folgt aussehen:

 ...
if vresult_ind >= 0;

  Select;
  When vtype = '1';
    // Character 
    exec Sql GET DESCRIPTOR 'mydesc' VALUE :i :sp2 = DATA;
  
  When vtype = '4';
    // Integer 
    exec Sql GET DESCRIPTOR 'mydesc' VALUE :i :sp1 = DATA;
  endsl;
  
endif;

Damit brauchst du die Spalten nicht alle Definieren, du musst halt nur aufpassen dass du für jedes Feld eine passende Variable zur Verfügung hast.

lg Andreas

[Fuerchau]

Ich denke nicht dass die SQL-Vorschläge hier helfen, da das After/Bevor-Image wohl nicht als Einzelsatz in einer Tabelle sondern als Gesamtpuffer von einem Trigger irgendwo gespeichert ist.

Hier müsste ich ein neues Konzept erstellen und somit eine neue Tabelle (auf Basis der alten + Identity-Bezug mit B/A-Kennzeichnung) erstellen und ein feldbezogenes After/Bevor-Image per Trigger schreiben.
Dann kann ich per dynamischem SQL die Felder vergleichen und für eine Subfile-Ausgabe auch mittels CHAR(NumFeld) einfach aufbereiten.

[Fuerchau]

Um überhaupt mit Descriptoren zu arbeiten musst du diese auch erstellen, automatisch steht da nichts zur Verfügung.
Beispiele stehen im Handbuch SQL-Programming.

Im wesentlichen sind dies:
Allocate descriptor ...
Describe xxx using descriptor ...
fetch ... into descriptor ...

Dann kannst du auch per "Get Descriptor ... DATA" den Inhalt (sowie Attribute usw.) auslesen.
Benötigt wird hierfür aber ein dynamischer SQL auf Feldebene!

[andreaspr@aon.at]

... ums noch genauer zu beschreiben:
var = 'select ...'
prepare s1 from :var
decalare c1 cursor for s1
allocate descriptor 'xxx' ...
describe s1 using descriptor 'xxx'
open c1
fetch c1 into sql descriptor 'xxx'
// anzahl der spalten abrufen
get descriptor 'xxx' :count = count
dann in einer Schleife für jede Spalte (i = Spaltennummer):
get descriptor 'xxx' value :i :type=type, ...
und dann wie oben von mir schon beschrieben mit
get descriptor 'xxx' value :i :vdata = data

[Fuerchau]

Manchmal frage ich mich, warum immer alles so kompliziert sein muss.
Mit einer dynamischen SQLDA bekomme ich auch alle Informationen sowie beim Fetch auch gleich die Inhalte. Durch Typanpassung kann ich immer ein CHAR/VARCHAR-Feld als Ziel angeben.
Ich muss nur halt die SQLDA per %alloc() anlegen, im Array der SQLItem's je Variable einen %alloc() für einen Speicherbeireich durchführen.
Wenn ich dann fertig bin, kann ich alles per %free() wieder freigeben.

Descriptoren machen eigentlich nur bei Sprachen Sinn, die keine dynamische SQLDA unterstützen.

Mit V4R3 habe ich einen SQLCPY entwickelt (in meinem Download zum Test verfügbar), der genau nach diesem Verfahren arbeitet.