Berechtigung QSYS View ermöglichen

[Fuerchau]

Mach mal einen DSPFD der View für die UserInfo.
Dort kannst du dir den SQL genau ansehen.
U.U. wird in from "table(getirgendwas(p1, p2))" gelesen, da durchaus 2 API's eine Rolle spielen können.
Ein List-API für USRPRF-Objekte und ein USRINFO-API je User.
Somit könntest du die Inner-Function ganz genauso aufrufen.
Ich kann das i.M. nicht online verifizieren, aber es aber bei anderen Systemviews genau so gesehen.

[Gutmann]

Hallo Herr Fürchau, a

lso das CREATE bzw. das FROM sieht wie folgt aus:

SELECT * FROM TABLE (QSYS2.OBJECT_STATISTICS('QSYS      ','USRPRF ',NULL)) a, lateral (SELECT * FROM TABLE (QSYS2.QSYUSRINFO(a.OBJNAME)) as x) as b;

Wenn ich das so ausführe braucht es immerhin nur 500 ms.
Die Objectstatistics allein bringt mir nichts, die qsyusrinfo aber auch nicht, da hier der User fehlt. Da es ja nicht nur um den einen geht, muss ich sie eben joinen über den LATERAL SELECT wie oben zu sehen.
Den Befehl DSPFD kannte ich so gar nicht, ich bin immer über SCHEMATA u. SQL generieren gegangen
Wenn ich nun aber eine View anstelle der UDF mache, wie kriege ich das dann mit den Rechten hin?

[Fuerchau]

"QSYS2.OBJECT_STATISTICS('QSYS ','USRPRF ',NULL)"

Die Funktion nimmt 3 Parameter:
1. Lib
2. ObjType
3. wahrscheinlich OBJNAME, wobei NULL dem *ALL entspricht.

Wahrscheinlich kann man das auch für andere Objekttypen verwenden.

"QSYS2.QSYUSRINFO(a.OBJNAME)"

Damit hast du doch genau die Funktion, die du eigentlich willst:
Parameter dürfte der Username sein, was durch den Join vom 1. API ermittelt wird.

SELECT * FROM TABLE (QSYS2.QSYUSRINFO("MEIER"))

sollte also genau von enem User die Info bringen.