naja, mit dem Betriebsrat - zu meinen Angestelltenzeiten hatte ich mal einen, der war nicht gekauft, der war geschenkt, der machte das umsonst - ich finds schon gut, wenn die Jungs (und Mädels) ein offenes Auge haben.

mit den stored Procedures - das wäre Applikationslogik in der Datenbank, das ist gegenwärtig out.

mit dem Owner - das ist originäre SQL Logik:
- Benutzername = Schemaname ist Owner der Datenbank
- Ownerprofile sind nicht anmeldbar
- alle Berechtigungen sind ohne GRANT exclude
- Applikation connected mit selbigem User
- die SQL Zugriffe brauchen nicht qualifiziert werden
- die Applikation darf alles
- ohne den Owner Connect darf man nix
- Zugriff nur über Views mit Grants
dies alles geht mit embedded SQL (und CLI) in RPG in lokalen Applikationen nicht, weil man automatisch connected wird.

mfg

Dieter Bender


Zitat Zitat von Fuerchau
OffTopic !

Gerade das mit dem ApplikationsUser (feste Anmeldung mit einem internen Profil und Kennwort) gestaltet sich gerade bei Java-Anwendungen als schwierig, da viele Aktionen mit dem DB-Register "Current User" geregelt werden. Arbeiten nun alle unter dem selben User gibts schon Probleme (z.B. Applikations-Berechtigung auf User-Ebene), insbesonder bei einer späteren vom Betriebsrat ungern gesehenen Journal-Auswertung (naja, der Betriebsrat fände die Idee wieder Klasse) sowie dem User-gesteuerten Accounting (Account-Codes im User-Profil).

Solange ich reine 5250-Anwendungen habe kann ich mit dem AppUser (Owner-Trick) ganz gut arbeiten.
Bei ODBC funktioniert das leider nicht mehr oder ich machs auf die ganz harte Tour:

Zugriffe ausschließlich mittels SQL-Prozeduren, die wiederum unter Owner (AppUser) laufen.
Native DB-Zugriffe sind dann natürlich verboten.
Charmanter Vorteil: es gibt nur zugelassene und performante Zugriffe und keinen Wildwuchs

Aber ehrlich, wer designed so eine Anwendung ?