... bei DRDA (ArdGate) ist die Sache folgendermaßen:
Zu unterscheiden ist erst mal static SQL und dynamic SQL:
- static SQL: beim compile wird das select statement an die Datenbank geschickt und die Datenbank hat die Gelegenheit dieses zu prüfen und (optional) ein Package zu erstellen (bei lokalem RPG ist die Teil des Programms) und eine SQLDA zurückzugeben (die dann gegen den fetch geprüft werden kann). Der Precompiler erstellt sich dann die entsprechenden Variablen zum einlesen und die entsprechenden Zuweisungen an die Hostvariablen, letzteres passiert auch für andere Hostvariablen.
Beim automatisch erfolgenden prepare kriegt die Datenbank das SQL statement und antwortet mit einer SQLDA. Beim Open wird das Resultset erstellt. Beim fetch werden dann die Felder des Resultsets nach Reihenfolge in die Hostvariablen übertragen.
Beim dynamischen SQL fällt der Compileschritt für die DB weg (das Statement ist nicht bekannt). Ansonsten geht das wie gehabt.

Verglichen mit RLA wird bei SQL grundsätzlich Feldweise übertragen und zwar der Reihenfolge der Felder im Resultset nach in die Hostvariablen, wobei bei Datenstrukturen und Indicator Arrays beim Compile in die Einzelfelder aufgelöst wird.

An diesem Mechanismus hat sich seit ewigen Zeiten (gefühlt 1870) nix geändert, auch nicht bei V7. Das funktioniert auch immer klaglos, solange man die Reihenfolge der Felder nicht verwürfelt und keine unverträglichen Änderungen an Feldtypen vornimmt. Passt irgendwas nur fast in Typ oder Anzahl, dann kommt ein SQLCODE > 100 zurück, falls die Runtime meint, sie hat das hingekriegt, wenn sie meint das kann sie nicht, kommt ein negativer SQLCODE zurück. Auch hier hat sich am Sollzustand nix geändert, ich vermute allerdings, dass es hier mit dem ganzen verwürfeln der Query Engines (welcher Trottel hat da gemeint man braucht mehrere konkurrierend) reichlich Bugs in der Implementierung zu finden sind, die je nach Release mal dies, mal jenes machen. (Das mit den Warnings hat bereits unter älteren Releses die Joblogs vermüllt, wie Mr. google offenbart)

Nach meiner Erfahrung gibt es zwei stabile Wege damit umzugehen:
- select Feldliste fetch into (kopierte) Feldliste
- select * fetch into externe DS
jeder Mix überkreuz kann zu unerwünschten Nebenwirkungen vor oder nach dem Compile führen.

Probleme hält man sich ganz einfach vom Hals:
- nur über Views zugreifen und eine View nie ändern (stattdessen eine zusätzliche und ab und an nicht mehr benötigte wegschmeißen)

Selbstredend sollte man SQLCode (oder SQLSTATE) fleißig und korrekt abfragen - eine der beliebtesten Fehlerquellen.

D*B