SQL Stored Procedure / Bibliotheksliste

[olbe]

Hi,
ich versuche mich gerade mal an Stored Procedures und hätte da jetzt ein "Problem" (oder eher einen unschönen Zustand).

Nachfolgend erst einmal die Stored Procedure:
CREATE PROCEDURE rlbo.cp1_get(IN com_partner CHAR(10), OUT tmp_last DECIMAL(9,0), OUT tmp_dir CHAR(30), OUT tmp_file_p CHAR(4), OUT err_flag CHAR(1))
LANGUAGE SQL
MODIFIES SQL DATA
BEGIN
DECLARE last_rec CHAR(1) DEFAULT 'N';
DECLARE tmp_low DECIMAL(9,0);
DECLARE tmp_high DECIMAL(9,0);
DECLARE cursor1 CURSOR FOR SELECT p1slow, p1shig, p1slas, p1hdir, p1fpri
FROM c82f.cp1
WHERE cp1mnd = 0 AND cp1id = 'P1' AND p1comp = com_partner AND p1kzsr = 'S';
DECLARE CONTINUE HANDLER FOR NOT FOUND
SET last_rec = 'Y';
OPEN cursor1;
fetch_loop:
LOOP
FETCH cursor1 INTO tmp_low, tmp_high, tmp_last, tmp_dir, tmp_file_p;
IF last_rec = 'Y' THEN
LEAVE fetch_loop;
SET err_flag = 'Y';
ELSE
IF tmp_last >= tmp_high THEN
SET tmp_last = tmp_low;
END IF;
SET tmp_last = tmp_last + 1;
SET err_flag = 'N';
UPDATE c82f.cp1
SET p1slas = tmp_last
WHERE CURRENT OF cursor1;
END IF;
END LOOP fetch_loop;
CLOSE cursor1;
END

Aufruf im ILE-RPG:
/free
EXEC SQL CALL rlbo/cp1_get(:$i_c_com_part,
:$o_s_cp1_count,
:$o_c_cp1_path,
:$o_c_cp1_fpre,
:$o_c_cp1_err);
/end-free

Die Stored Procedure holt aus einer Zählertabelle (CP1) den letzen Stand des Zähler (+ weitere Parameter) , zählt diesen hoch, schreibt den aktuellen Wert in die Tabelle zurück und gibt verschiedene Werte an das aufrufende ILE-RPG zurück.

Mein Problem ist nun, daß ich sowohl in der Stored Procedure wie auch im ILE-RPG die Bibliothek fest hinterlegen muss, da ich ansonsten die SQL-Fehlermeldung 42704 (An undefined object or constraint name was detected) erhalte.

Gibt es eine Möglichkeit, das ganze ohne die fest definierten Bibliotheken zu lösen?


Vielen Dank.

[BenderD]

Hallo,

der SQL Standard kennt keinen Libl (man denke eine SQL Datenbank mit referential constraints und dann sage ich: seh mal zu wo du einen Artikelstamm zu meinen Aufträgen findest...), sondern arbeitet mit einem default schema für nicht qualifizierte Angaben, wird kein default schema festgelegt, nimmt SQL an, dass das schema wie der Benutzer heißt, der beim connect angegeben wird (hier steigt dann die AS/400 meist aus, da man im 5250 nicht connect sagen soll wg.CFINT).
Als Workaround der DB2/400 (UDB, ein Marketing Gag!!!) gibt es dann den Parameter NAMING(*SYS), mit dem man den qualifier von "." auf "/" umstellen kann (gegen den SQL Standard) und das default schema gegen *LIBL getauscht wird, ob und wie das auch bei SQL Procedures geht kann ich nicht aus eigener Erfahrung berichten, da ich mich am SQL Standard orientiere.

mfg

Dieter Bender

[B.Hauser]

Hallo,

System-Naming funktioniert auch mit SQL Stored Procedures!

Allerdings kann man das verwendete Naming nicht über ein SET OPTION-Statement setzen. (Das ist nur bei embedded SQL zulässig).

SQL Stored Procedures verwenden das Naming unter dem sie erstellt wurden.

Wird die Stored Procedure unter STRSQL erstellt, wird per Default SYS-Naming verwendet. Über F13, Auswahl 1 kann man das zu verwendende Naming einstellen.

Wird die Stored Procedure über iNavigator --> SQL Prozedur ausführen erstellt, wird per Default SQL-Naming verwendet. Über JDBC-SetUp lässt sich auch hier das Naming verändern.

Wird die Stored Procedure über RUNSQLSTM erstellt, kann das Naming im RUNSQLSTM-Befehl (sowie z.B. auch die Datenbibliothek) direkt festgelegt werden.

Übrigens es gibt zwischen SQL und System-Naming noch einige andere Unterschiede als die Angabe von . oder / als Qualifikations-Trennzeichen. Insbesondere bei den Berechtigungen und wem das Objekt gehört gibt es eklatante Unterschiede. Bei System-Naming funktioniert es so, wie wir es auf der AS/400 (oder wie auch immer) gewohnt sind. Bei SQL-Naming wird sich so mancher wundern, dass man z.B. ein Objekt erstellen kann, aber Berechtigung an einem Benutzer-Profil braucht, um Änderungen am Objekt vorzunehmen.

Birgitta

[BenderD]

was ist da bei SQL verwunderlich?
die Objekte gehören dem Ersteller, der auch bei SQL dann alle Berechtigungen hat, die Public Berechtigung ist bei SQL Standard (naming *SQL) immer *exclude und man macht dann eventuell erforderliche Grants direkt im selben Skript (ein Grund von vielen warum Ooops Nerv und das Maus Gezappel für mich ein Rückschritt ist).
Die Standard SQL Vorgehensweise ergibt sich daraus (fast) von selbst:
In der Test und Entwicklungsphase werden die Objekte vom Programmierer erstellt, dessen Standard Schema so heißt wie sein Benutzer und in den Skripten wird nichts qualifiziert und alles passt, auch von der Berechtigung. (Die Testumgebung wird dann mit Duplikaten und Alias mit abhängigen Objekten ergänzt).
Für Produktionseinsatz gibt es einen Benutzer, der so heißt wie das Production Schema, wandelt man unter dem, wird alles in der Prod Lib erstellt und wieder passt alles zusammen. Für den Zugriff auf diese Daten macht man einen Connect unter dem passenden Datenbankbenutzer und wieder passt alles zusammen, alle Berechtigungen werden in der Applikation kontrolliert und auf die Daten kommt man ansonsten nur drauf, wenn eine entsprechende Berechtigung eingeräumt wurde.
Hemmend ist da allenfalls, dass die DB2/400 eben nicht UDB ist und der lokale Connect im RPG etwas hakelig ist (Stichwort: Server Mode).

D*B

Übrigens es gibt zwischen SQL und System-Naming noch einige andere Unterschiede als die Angabe von . oder / als Qualifikations-Trennzeichen. Insbesondere bei den Berechtigungen und wem das Objekt gehört gibt es eklatante Unterschiede. Bei System-Naming funktioniert es so, wie wir es auf der AS/400 (oder wie auch immer) gewohnt sind. Bei SQL-Naming wird sich so mancher wundern, dass man z.B. ein Objekt erstellen kann, aber Berechtigung an einem Benutzer-Profil braucht, um Änderungen am Objekt vorzunehmen.

Birgitta

[olbe]

Vielen Dank für Eure ausführlichen Antworten!

Auch wenn ich nicht alles verstanden habe, komme ich damit schon mal grundsätzlich weiter.