PDA

View Full Version : andere Berechtigung in SQL-Unterprogramm?



Seiten : [1] 2

rebe
15-06-06, 14:20
Hallo,

ich habe ein SQLCBLLE-Programm, das einen SELECT-Befehl auf eine Datei macht, auf die nur wenige Benutzer Berechtigung haben.
Was muß ich tun, damit dieses Unterprogramm Berechtigung auf diese Datei hat? Ich dachte beim Umwandeln (CRTSQLCBLI) gebe ich bei Benutzerprofil USRPRF *OWNER an und dann geht's. Leider nicht. Muß ich innerhalb des Programms einen neuen CONNECT machen mit einem Benutzerprofil das Berechtigung auf die Datei hat? Wenn ein Parameter beim Umwandeln dafür zuständig ist, würde ich lieber das machen.

Danke für Tipps.

Grüße
Reiner

Fuerchau
15-06-06, 14:26
Probiers mit
/exec sql set option usrprf=*owner
/end-exec

rebe
15-06-06, 15:08
Probiers mit
/exec sql set option usrprf=*owner
/end-exec

Danke für den Beitrag.
Das sollte ja eigentlich das gleiche sein wie USRPRF(*OWNER) beim Umwandeln. Es kommt immer noch die Fehlermeldung "keine Berechtigung" SQL0551.

Reiner

BenderD
15-06-06, 15:46
Hallo,

die Problem beschreibung ist ein wenig zu allgemein gehalten:
bei dynamischem SQL muss zusätzlich DYUSRPRF auf Owner gestellt werden (beim Compile, oder set option, was ebenfalls zur Compiletime wirkt.
Bei remote Zugriff wird als Owner immer der Owner des Packages gezogen, was beim deployment zu Problemen führen kann, da gehören die Packages zuweilen dem QUSER.

mfg

Dieter Bender


Hallo,

ich habe ein SQLCBLLE-Programm, das einen SELECT-Befehl auf eine Datei macht, auf die nur wenige Benutzer Berechtigung haben.
Was muß ich tun, damit dieses Unterprogramm Berechtigung auf diese Datei hat? Ich dachte beim Umwandeln (CRTSQLCBLI) gebe ich bei Benutzerprofil USRPRF *OWNER an und dann geht's. Leider nicht. Muß ich innerhalb des Programms einen neuen CONNECT machen mit einem Benutzerprofil das Berechtigung auf die Datei hat? Wenn ein Parameter beim Umwandeln dafür zuständig ist, würde ich lieber das machen.

Danke für Tipps.

Grüße
Reiner

rebe
15-06-06, 15:56
Hallo Dieter,

es ist kein dynamisches SQL und auch kein Remote-Zugriff.

Es geht darum, daß ein Unterprogramm Zeiten von Mitarbeitern ermitteln soll. Dieses Unterprogramm benutzt SQL-Befehle (select). Der User, der das Hauptprogramm aufruft, hat keine Berechtigung auf diese Stundendatei. Damit das Unterprogramm aber die Stunden holen kann, muß es mit einem anderen Benutzerprofil auf die Daten zugreifen. Das versuche ich zu programmieren.

Alles klar soweit?

Reiner

BenderD
15-06-06, 16:17
Hallo,

genau für diesen Fall gibt es ja diesen Compile Parameter und der funzt bei mir eigentlich immer, es muss da also eine spezielle Konstellation vorliegen. Was meint hier eigentlich Unterprogramm? Sind da noch SQL Programme drüber? Hast du mal alle SQL Programme im Call stack mit Owner umgewandelt? Oder ist das ILE und hast du dem "Unterprogramm" mal eine eigene Activationgroup verpasst? Gibt es weitere Meldungen im Joblog? Hast du das ganze mal unter Debug gemacht, um sicher zu gehen, dass der Fehler auch an dieser Stelle auftritt?

mfg

Dieter Bender


Hallo Dieter,

es ist kein dynamisches SQL und auch kein Remote-Zugriff.

Es geht darum, daß ein Unterprogramm Zeiten von Mitarbeitern ermitteln soll. Dieses Unterprogramm benutzt SQL-Befehle (select). Der User, der das Hauptprogramm aufruft, hat keine Berechtigung auf diese Stundendatei. Damit das Unterprogramm aber die Stunden holen kann, muß es mit einem anderen Benutzerprofil auf die Daten zugreifen. Das versuche ich zu programmieren.

Alles klar soweit?

Reiner

Fuerchau
15-06-06, 18:22
Ein solches Unterprogramm muss sowohl mit *OWNER im Programm als auch per USRPRF=*OWNER im SQL erstellt werden.
Wenn es innerhalb einer bestehenden SQL-Session aufgerufen wird, erfolgt keine neue SQL-Anmeldung (intern wird automatisch connected) sondern die aktuelle Sitzung verwendet.
Es ist also auf jeden Fall eine eigene Aktivierungsgruppe erforderlich um nicht in bestehende SQL-Sessions hineinzugeraten.

rebe
16-06-06, 08:20
Das Problem ist gelöst, bzw. umgangen.
Danke für alle Beiträge.

Zuerst habe ich das Programm in ILE COBOL geschrieben. Bin halt in RPG noch nicht so fit. Dann habe ich das Programm spaßeshalber mal in RPG geschrieben und siehe da, es funktioniert sofort. Sch... COBOL!
Wahrscheinlich geht es in COBOL auch, aber habe keine Lust da jetzt weiter rumzuhexen.

Grüße
Reiner

rebe
19-06-06, 13:02
Hallo,

das Problem ist doch nicht gelöst. Ich habe da eine Kleinigkeit übersehen. Zwischendurch habe ich zum Test dem User mal die Berechtigung *USE für die Datei gegeben und vergessen, das wieder rauszunehmen, dann ist klar, daß es geht. :rolleyes:

Nehmen wir mal die RPG-Version. Damit beschäftigen sich wohl mehr hier. Zum Testen rufe ich das Programm einfach per Call auf, nicht aus einem übergeordneten Programm.

Im Programm habe ich DFTACTGRP(*NO) ACTGRP(*NEW) gesetzt. Zusätzlich noch "set option usrprf = *owner".
Berechtigung auf die Datei ist PUBLIC *EXCLUDE. Ich als Umwandler des Programms habe *ALL.
Beim Ausführen des Programms mit einem dummen User bekomme ich ein CPF4269 (Keine Berechtigung für Objekt ...).
Hat jemand eine Idee was ich probieren kann?

Danke für eure Unterstützung schon mal.

Grüße
Reiner

Fuerchau
19-06-06, 13:28
Und das Programm selber läuft auch unter *OWNER ?