Berechtigung einer view

[Robi]

Also ...
Anschl. ein CL aufrufen ist 'unglücklich' ( wer denkt daran)

Also habe ich in in der Source
GRANT ALL ON AKTENJ01 TO Myprofile;
GRANT ALL ON AKTENJ01 TO EDVProfil;

eingefügt.

Ich habe nun alle Berechtigungen, EDV-Leiter nicht.
Objektberechtigung bei beiden: USER DEF
EDV hat am Objekt nur Opr, Ändern und Ref.
und an den Daten nur Lese.
Ich hab Lese und Ausf. sowie Opr, Verw, Exist., Ändern und Ref.

*PUBLIC (den verändere ich nicht) hat Lese + Ausf. bzw nur Opr

Was muß ich tun, um dem EDV-Leiter ein echtes ALLl zu geben

Robi

[Fuerchau]

SQL unterstützt das Berechtigungskonzept Berechtigungsliste leider nicht.
Hier ist der normale GRTOBJAUT erforderlich.
Wenn die Lib entsprechend mit Berechtigungsliste geschützt ist, benötigt man keine speziellen Berechtigungen an den einzelnen Objekten. Man kann dann PUBLIC alle rechte geben. Es kommen eh nur die User dran, die für die Lib berechtigt sind sowie die *ALLOBJ-User.

Ab wann die DB2/400 mal Rollen unterstützt müsste Birgitta beantworten können.

[BenderD]

... normalerweise hat man ein Erstellunsscript, das man mit RUNSQLSTM und da kann man auch einen GRTOBJAUT per stored procedure call auf QCMDEXC hinterherdüsen.

D*B

Also ...
Anschl. ein CL aufrufen ist 'unglücklich' ( wer denkt daran)

Also habe ich in in der Source
GRANT ALL ON AKTENJ01 TO Myprofile;
GRANT ALL ON AKTENJ01 TO EDVProfil;

eingefügt.

Ich habe nun alle Berechtigungen, EDV-Leiter nicht.
Objektberechtigung bei beiden: USER DEF
EDV hat am Objekt nur Opr, Ändern und Ref.
und an den Daten nur Lese.
Ich hab Lese und Ausf. sowie Opr, Verw, Exist., Ändern und Ref.

*PUBLIC (den verändere ich nicht) hat Lese + Ausf. bzw nur Opr

Was muß ich tun, um dem EDV-Leiter ein echtes ALLl zu geben

Robi

[B.Hauser]

da kann man auch einen GRTOBJAUT per stored procedure call auf QCMDEXC hinterherdüsen.

D*B

... oder ab Release 6.1 den CL-Befehl direkt im Skript mit führendem CL: hinterlegen.

Birgitta

[Fuerchau]

Scripte mit RUNSQLSTM sind meines Erachtens die unsicherste Methode da man die einzelnen SQL's leider nicht überwachen kann.
Beim 1. Fehler wird abgebrochen.
Wenn dann auch noch CL-Befehle dazukommen ...

[BenderD]

... deswegen lässt man die mit Commit düsen, wenn man das dann per SBMJOB macht, werden die bei korrekter Handhabung sogar automatisch zurück gesetzt.

D*B

Scripte mit RUNSQLSTM sind meines Erachtens die unsicherste Methode da man die einzelnen SQL's leider nicht überwachen kann.
Beim 1. Fehler wird abgebrochen.
Wenn dann auch noch CL-Befehle dazukommen ...

[Robi]

@Fuerchau
sehe ich ähnlich, ist aber praktikabel

@Birgitta
ist nur V5R4 (kannte ich auch noch nicht)

@Dieter
Prima, danke
call qcmdexc('grtobjaut ...', 52) im sql-script kannte ich nicht.
Funktioniert aber, Danke