PDA

View Full Version : Mit dem Bagger durch die Eifel oder wie debugge ich eine SQL Prozedur



KingofKning
01-11-19, 11:30
Hallo *all,
ich habe hier eine SQL UDF die nicht das macht was ich erwarte.
Also wollte ich mal den Bagger anwerfen um das zu prüfen. Habe ich allerdings noch nie gemacht, deswegen klappt es auch noch nicht.

Schritt eins:



CREATE FUNCTION rptrade/zaehler /*01.11.19 12:05*/
( DEBITOR dec(08) ) RETURNS dec(05)
Language SQL
Modifies SQL Data
Deterministic
Specific zaehler
Called on NULL Input

Set Option
DATFMT = *ISO,
DBGVIEW = *SOURCE,
DECMPT = *COMMA,
TIMFMT = *ISO
BEGIN
DECLARE RETURNVAL dec (05) DEFAULT 0;
DECLARE anzahl decimal(05) DEFAULT 0;
DECLARE i_zaehler decimal(08) DEFAULT 0;

select debgh(dec(debitor)) into i_zaehler
from dat018
fetch first row only;
if i_zaehler = 0 then
select d020werta into i_zaehler
from dat020 where d020key = debitor;
end if;
if i_zaehler = 0 then
select d020werta into i_zaehler
from dat020 order by d020werta desc
fetch first row only;
set i_zaehler = i_zaehler + 1;
insert into dat020 (d020key, d020werta)
values(debitor, i_zaehler);
end if;
set returnval = i_zaehler;
RETURN RETURNVAL;
END


Schritt zwei:
536

Das Problem ist ja hier schon das ich keinen Parameter mitgeben kann.
537

Aber vielleicht kann mir ja auch so einer einen Tipp geben.



select debgh(dec(debitor)) into i_zaehler
from dat018
fetch first row only;
if i_zaehler = 0 then


Die Funktin liefert unter bestimmten Umständen eine 1 zurück das heißt der Rest dürfte dann nicht ausgeführt werden und die ganze Funktion gibt mir eine 1 zurück. Tut sie aber nicht. Ich vermute das diese Zeile oben nicht passt.

Für Hinweise dankbar. Benutzen tue ich den Iseries Navigator V6R1M0

GG 4229

andreaspr@aon.at
01-11-19, 13:09
Hallo,

den Navigator hab ich schon lange nicht mehr im Einsatz und weiß deshalb leider nicht mehr genau wie ich das dort damals gemacht habe.
Du kannst jedoch im Green-Screen via STRDBG oder im RDi SQL Funktionen oder Prozeduren debuggen.
Bei einer SQL Funktion wird ein SRVPGM erstellt dass bei dir rptrade/zaehler heißen sollte.
Beim STRDBG musst du dann einfach nur das SRVPGM angeben und fertig.
Der Befehl müsste dann bei dir wie folgt sein:
STRDBG UPDPROD(*YES) SRVPGM(rptrade/zaehler)

Dann die Break Points setzen und dann z.B. im STRSQL dein Select ausführen.

Das gleiche Prinzip ist auch im RDi möglich. Dort verwendest du aber am besten den "Debug für Job".

Aja, beim CREATE FUNCTION musst du NOT FENCED verwenden, da sonst das SQL in einem anderen Thread ausgeführt wird und du nicht in den Debugger reinspringst.

lg Andreas

Fuerchau
01-11-19, 13:55
SQL-Prozeduren/Funktionen lassen sich auch häufiger nur per STRSRVJOB (oder wars STRSVRJOB?) debuggen.
Also STRSRVJOB des Zieljobs, also der Job der STRSQL ausführt.
Und dann den STRDBG des Service-Progs aufrufen.

B.Hauser
01-11-19, 15:55
Das Problem beim Einsatz von STRDBG und STRSRVJOB ist, dass nur der generierte C-Code gedebugged werden kann.
Der in Client Access und ACS intergrierte Debugger erlaubt den SQL Code zu debuggen (sofern SET OPTION DBGVIEW=*SOURCE angegeben wurde).

Man startet den Debugger aus der aktuellen Umgebung (also aus dem "Run an SQL Script" bzw. "Eine Prozedur ausführen). Gibt das Programm (Stored Procedure) oder Service-Programm (UDF oder UDTF) an. Falls Du mit langen Prozedur-Namen arbeitest oder mit Überladung, solltest Du den (Service-)Programm-Namen zunächst exakt ermitteln/prüfen.
Wurde das (Service-)Programm korrekt angegeben, sollte es unter Programm-/Service-Programm auf der linken Seite angezeigt werden. Sobald man auf das (Service-)Programm positioniert, wird der Source Code (großes Fenster) geladen. Mit F6 können dann Break-Points gesetzt werden.
Anschließend führt man das/ein SQL-Statement aus dem "Run SQL Script" aus, aus dem die Funktion aufgerufen wird. Der Debugger sollte dann beim 1. Break-Point stehen bleiben.

Wichtig: Achte darauf, dass die Option "Include Debug Messages in Joblog" nicht gesetzt ist. Ansonsten bekommst Du ziemlich wilde Fehlermeldungen und kannst den Debugger nicht starten.

Birgitta

andreaspr@aon.at
01-11-19, 16:11
Das Problem beim Einsatz von STRDBG und STRSRVJOB ist, dass nur der generierte C-Code gedebugged werden kann.
Der in Client Access und ACS intergrierte Debugger erlaubt den SQL Code zu debuggen (sofern SET OPTION DBGVIEW=*SOURCE angegeben wurde).

Vielleicht noch zur Ergänzung ...
Genau, es wird lediglich der C-Code debugged, jedoch kann man in der Debug Ansicht SQL auswählen, bzw. sollte sowieso default sein.
Dadurch sieht man lediglich den SQL Teil und nicht den dahinterliegenden C-Code.

Beim ACS ist es schöner umgesetzt, denn dort werden bei jedem SQL Step wirklich alle C-Code Zeilen übersprungen die hinter diesem SQL Step stehen. Im STRDBG muss man auf der gleichen Zeile mehrmals F10 drücken bis alle dahinter liegenden C-Zeilen durchlaufen sind.
Im ACS springt man sofort zur nächsten Anweisung.

KingofKning
01-11-19, 20:23
Also der erste Versuch hat jetzt noch nicht geklappt, aber ich werde es morgen nochmal probieren.
Erstmal Danke für die Hinweise.

GG 4229

Fuerchau
02-11-19, 16:09
Immer noch besser den C-Code als gar nicht zu debuggen;-).

KingofKning
03-11-19, 18:11
Immer noch besser den C-Code als gar nicht zu debuggen;-).
Na ja, als ehemaliger Dozent für die Sprache C an der VHS sollte das jetzt nicht das Problem sein. ;-)
Schade das es keinen P-Code erzeugt bzw. Maschinensprache.
Meine alte B10 Kiste hatte beim compilieren noch die Option P-Code anzuzeigen. Leider hat die Kiste mich verlassen.

GG 4227

Fuerchau
04-11-19, 07:59
Prüfe mal die Berechtigungen des STRSRVOB-CMD's. Ich denke, der wird auch benötigt beim Debugger per CA/ACS.