*NODEBUGIO Pendant für embedded SQL Statements im Debug

[Etherion]

Hallo zusammen,

ich habe mit einer Unschönheit zu kämpfen, wenn ich SQLRPGLE Programm debuggen möchte.

Bei meinem u. g. Beispiel muss ich beim SQL Fetch 13 Mal die Step Funktionstaste drücken bevor der Debugger eine Codezeile weiterspringt (siehe originaler Sourcecode).

Die Erklärung dafür ist wohl im Quellcode des SQL Precompilers zu finden. Es werden 13 Befehle generiert, die zwar im Debugger nicht angezeigt werden, die aber Step für Step abgearbeitet werden (siehe Code des SQL Precompilers).


Für die nativen RPG I/O Operationen gibt es ja die Option *NODEBUGUIO, die dafür sorgt, dass bei einem I/O Zugriff der Befehl in einem Step abgearbeitet wird.

Gibt es etwas Vergleichbares für die SQL Zugriffe? Oder wie kann man den Debugger überlisten?

Originaler Sourcecode
// Arbeitsdatei Lohn ERA durchlesen
exec sql fetch next from lohnerac into :lohneraf;
dow (SQLCOD = 0);

Code des SQL Precompilers
// Arbeitsdatei Lohn ERA durchlesen
//* exec sql fetch next from lohnerac into :lohneraf;
SQLER6 = -4;
SQLROUTE_CALL(
SQLCA
: SQL_00006
);
IF SQL_00009 = '1';
EVAL BUDAT = SQL_00011;
EVAL KOSTENST = SQL_00012;
EVAL KOSTENSTB = SQL_00013;
EVAL KTONR = SQL_00014;
EVAL BUTEXT = SQL_00015;
EVAL MENGE = SQL_00016;
EVAL BETRAGS = SQL_00017;
EVAL BETRAGH = SQL_00018;
EVAL STEUERB = SQL_00019;
EVAL STEUCD = SQL_00020;
ENDIF;
dow (SQLCOD = 0);

Gruß Stefan

[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.