Debuggen von SQL-Sitzungen

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