*NODEBUGIO Pendant für embedded SQL Statements im Debug

[Fuerchau]

Das ist der Nachteil eines Precompilers, der nun mal originären RPG-Code erzeugt.
Der RPG-Compiler weiß nichts von SQL und estellt eben für jede Zeile eine Debug-Info.

NODEBUGIO sorgt dafür, dass die ehemaligen I-Befehle (jetzt D) keine Debuginfo erhalten.
Denn nach dem IO-Read werden je Feld Move-Operationen ausgeführt, die sich in den I-Befehlen widerspiegeln.

Deshalb gibt es keine Möglichkeit, den Debug von SQL zu unterbinden.
Es hindert dich allerdings niemand daran, den SQL in eine Procedure zu packen, die dann tatsächlich mit nur einem Step(-over) getestet wird.

dcl-proc ReadCursorABC;
exec sql fetch ....
end-proc.

Du benötigst keine Aufruf- oder Returnparameter

Besser ist:
dcl-proc ReadCursorABC;
dlc-pi *n ind;
end-pi;
exec sql fetch ....
return sqlcode = *zero;
end-proc.

Somit kann man per
dow ReadCursorABC();
enddo;
bequem Schleifen aufbauen und debuggen.

[Etherion]

Hi Baldur,

Dankeschön für die schnelle Antwort und den guten Tipp.

Gruß Stefan

[xenofob]

Beim compilieren kann man unter dbgview *source angeben, dann sieht man die sql Internas nicht und muss weniger oft F10 drücken.

[Etherion]

Hi Xenofob,

ich arbeite noch unter dem Release 7.3 und ich bekomme für CRTSQLRPGI als dbgview sowieso nur *source und *none angeboten. Die Precompiler Quelle habe ich aus der Datei EVFTEMPF01, die zur Compilezeit erzeugt wird.

Mit welcher Betriebssystemversion arbeitest Du?

[Fuerchau]

dbgview *source dient nur dazu, den originalen Quelltext zu verlinken. Ansonsten stünde eben nur die RPG-Quelle für den Debug zur Verfügung, die man sich auch per F15 auswählen kann.
Das hat nichts mit den "Debug-Points" in der MI-Quelle zu tun, die der RPG-Compiler mit einbettet.
Somit ist jeder "eval SQLPARnn = HostField" und "eval HostField = SQLResultnnn" eben ein Einzelschritt im Code.

Ich habe nämlich auch mal einen MI-Compiler geschrieben, der mit diesen Debug-Infos eben auch ein MI-Programm Debugfähig gemacht hat. Allerdings nur der normle Debugger ohne Source.

By the way:
Habt ihr schon mal die generierte Quelle bei der Verwendung von NULL-Anzeigern und Date-Variablen analysiert?
Einfach einfach (Veranschaulichung):

  if SQLCODE = *zero;
      Hostvar1 = SQLVar1;
      NullInd1 = SQLNullVar1;
      If SQLNullVar2 = *zero;
         HostDateVarN = SQLVarN;
      endif;
      NullIndN = SQLVarN;
  endif;

Was soll mir das sagen?
Bei der Verwendung von NULL-Indikatoren werden alle Nicht-Date-Variablen mit ihrem Type-Default initialisiert Nur die Date-Variablen behalten ihren vorherigen Inhalt.

Das erklärte dann auch so diverse Programmierfehler, bei denen unerklärliche Datum-Variablen in Inhalten aus ganz anderen Zeilen auftauchten, da der NULL-Indikator nicht abgefragt wurde.