View Full Version : Debuggen von SQL-Sitzungen
Hallo Leute,
seit der Einführung von V6R1 beim Kunden kann ich SQL-Sitzungen nicht mehr debuggen (bzw. nur noch sehr sporadisch) um SQL-Prozeduren bzw. SQL-Funktionen zu testen.
Bis V5R4 konnte ich per
STRSRVJOB
STRDBG
von einer 2. Sitzung die 1. Sitzung in den Debug-Modus setzen.
In der 1. Sitzung habe ich dann per STRSQL meine SQL-Funktion aufgerufen und konnte dann schön im Einzelschritt debuggen.
Mit V6R1 stoppt der Debugger die Sitzung nicht mehr.
Weiß jemand Rat?
andreaspr@aon.at
01-06-12, 07:00
Dass die Sitzung nicht gestoppt wird, liegt normal daran, dass die Funktion nicht im aktuellen Job aufgerufen wird.
Eine ganz primitive Art herauszufinden wo die Funktion/Prozedur aufgerufen wird, ist ein QCMDEXC('SNDMSG ...') einzubauen.
lg Andreas
Nur so ein/zwei Fragen:
Warum brauchst Du eigentlich 2 Sitzungen um eine SQL Funktion zu debuggen?
Das sollte doch auch im gleichen Job funktionieren wenn Du den STRDBG vor dem STRSQL aufrufst (oder den Debugger über CALL QUSCMDLN über Befehlszeile in der aktuellen STRSQL session startest.)
Weiterhin warum verwendest Du nicht den im System i Navigator integrierten Souce Debugger?
Damit kannst Du SQL (sofern mit DBGVIEW *SOURCE umgewandelt), aber auch RPG, CL etc in externen Stored Procedures und User Defined Functions debuggen.
Birgitta
@Andreas
Dass die Funktion aufgerufen wird, erkennt man daran, dass die Dateien der Funktion im selben Job geöffnet werden.
@Birgitta
zu 1)
Dies ging ab irgendeiner V5-Version nicht mehr. Irgendwo hatte ich dann auch eine entsprechende Doku gefunden, dass es halt mit STRSRVJOB geht und dem war dann auch so.
Aktuell mit V6 geht es auch nicht mehr, ggf. liegt es ja auch an der Funktionsdeklaration (CREATE FUNCTION), aber die Doku gibt da nichts her.
Ggf. betrifft das ähnliche Änderung wie das Verwenden von SQL's in Funktionen, wenn die Deklaration da nicht passt (anderer Beitrag), was anscheinend bis V5R4 nur deklarativ war, also ignoriert wurde.
Ich denke, das muss irgendwie mit dem Threading von SQL zusammenhängen.
zu 2)
Ich arbeite halt aus Performancegründen am liebsten mit einer 5250-Sitzung, zumal ich immer noch zu einigen Kunden nur mit langsamen Leitungen (ISDN 64KB) arbeite.
Da ist der Aufwand über den Navigator einfach zu groß. Allein zum Starten brauch der ja schon 2 Minuten.
Ausprobiert habe ich das auch noch nie.
Es ist immer noch einfacher, den STRDBG direkt in der Sitzung zu starten als erst mühsam über den Navigator alles zu starten.
andreaspr@aon.at
01-06-12, 09:31
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
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.
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
01-06-12, 13:54
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 ...
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
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).