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
Zitat Zitat von B.Hauser Beitrag anzeigen
Ü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