SQL Stored Procedure / Bibliotheksliste

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