Debuggen von SQL-Sitzungen

[andreaspr@aon.at]

Hallo,

also ich habs jetzt mal bei uns probiert (7.1).

Job1:

create function pranlib/test2 (in1 integer)
returns integer                            
language sql                               
specific pranlib/test2                     
set option dbgview=*source                 
begin                                      
call qsys/qcmdexc('SNDMSG MSG(TEST) TOUSR(PRAN)', 0000000028.00000);
return 5;                                  
end

Job2:
STRSRVJOB
STRDBG SRVPGM(PRANLIB/TEST2)

Job1:
STRSQL
select test2(10) from sysibm/sysdummy1

Job2:
Bin im Debugger

Hast du die Funktion unter 6.1 neu erstellen lassen?
Vielleicht ist das erforderlich, da sich der C-Code im 6.1 eventuell ändert?
lg

[Fuerchau]

Native SQL-Function, da in C, werden wohl etwas anders behandelt.
Bei mir geht es ausschließlich external Function, da ich hier sog. SQL-Wrapper für die Standard-ERP-Aufrufe schreibe.

Die externe Funktion ist dann in ILERPG mit SQL-Interface, also Aufrufstil *SQL geschrieben.

Wie gesagt, bis 5.4 gings ja noch.
Programm und Create Function habe ich für V6R1 auch erneut durchgeführt.

[Fuerchau]

Habe mir mal den iNavigator Debugger angesehen.
Allerdings scheitere ich bereits beim Aufruf der SQL-Funktion, die angeblich nicht da ist (Signatur).

Zur Anmerkung:
Die Bibliotheksliste ist korrekt in den verbindungseigenschaften angegeben, im SQL wird mit dem SQL-Naming auch die Funktion qualifiziert aufgerufen.

Die Funktion wird zur Zeit in diversen anderen Programmen (Naming *SYS) sowie per ODBC (nicht JDBC wie im Navigator) und das funktioniert.

[andreaspr@aon.at]

Wenn es sich um ein RPG-PGM handelt, könntest du versuchen mit einem MSGW mit dem dsply-opcode den Job zu übernehmen.

C     'Debug'       dsply                   Antwort           1

Job 1: SQL-Anweisung im STRSQL

Job 2: dspmsg --> 5 --> F9 --> Jobnr usw. kopieren -->
STRSRVJOB --> Jobnr usw. einfügen
STRDBG ...

Zumindest weist du dann, unter welchem Job (Gruppenjob?) dein PGM wirklich läuft ...

[B.Hauser]

Zur Anmerkung:
Die Bibliotheksliste ist korrekt in den verbindungseigenschaften angegeben, im SQL wird mit dem SQL-Naming auch die Funktion qualifiziert aufgerufen.

Die Funktion wird zur Zeit in diversen anderen Programmen (Naming *SYS) sowie per ODBC (nicht JDBC wie im Navigator) und das funktioniert.

Mit welchem Naming arbeitest Du denn?
SQL oder System-Naming?
Mit welchem Naming wurde denn die Funktion erstellt?

Die Bibliotheksliste wird nur beim System-Naming verwendet, um sowohl die Dateien/Tabellen/Views als auch die anderen Datenbanken Objekte zu finden.

Beim SQL Naming werden Tabellen und Views in dem Default (=Benutzerprofil oder in JDBC/ODBC settings gesetzt) bzw. dem Current Schema (explizit mit SET SCHEMA gesetzt) gesucht. Stored Procedures bzw. UDFs werden dagegen im SQL Path gesucht. Der Default für den SQL Path ist QSYS, QSYS2, SSYSPROC, SYSIBMADM, USER (special register). Der SQL Path kann mit SET PATH explizit gesetzt werden. Der Sonderwert *LIBL ist dabei zu lässig (Im Gegensatz zum SET SCHEMA, bei dem nur ein einziges Schema angegeben werden kann).

Um irgendwelchen Mischmasch zu vermeiden, solltest Du alles auf System-Naming (wie im Green Screen) setzen und die Bibliotheksliste sauber versorgen. Dann klappt's auch mit der Debuggerei.

Birgitta

[Fuerchau]

Das waren eigentlich 2 verschiedene Themen im selben Thread.
Unabhängig vom Debuggen, beim Naming *SQL (Default) kann ich ja eine Fuktion qualifiziert mit MYLIB.MYFUNC(...) angeben. Über den Navigator findet er allerdings die Signatur nicht (JDBC) während es über ODBC funktioniert.
Aber letztlich ist mir das erstmal egal.

Warum funktioniert das Debugging nicht, war hier die Frage.
Den Grund habe ich nun herausgefunden:

Der neue Optimizer von V6R1 cached erheblich mehr als früher.
Wenn eine Funktion als "deterministic" definiert ist, speichert sich wohl SQL irgendwo die Parameterwerte und ruft die Funktion nicht mehr auf, da ja das Ergebnis das selbe sein wird.

Dies gilt sogar für ganze Ergebnistabellen.

Wiederhole ich also ein Statement mit F9, erfolgt also gar kein Aufruf meiner Funktion mehr.
Ich habe da mehrer Varianten versucht, sogar mit Job abmelden und neu anmelden.

Erst wenn ich das Statement irgendwie ändere verwirft SQL den Cache und ruft meine Funktion erneut auf.

ALso Leute:
Der Debugger funktioniert nun wieder so wie früher (allerdings immer noch nur per STRSRVJOB).