Benutzerverwaltung in Access

[Vaultboy]

Hallo liebes Forum,

ich habe eine kleine Adressdatenbank gestrickt. Das Frontend ist Access 2007 als Backend dient mir ein SQL Server 2008 R2. Soweit so klar. Allerdings wird an diese Adressdatenbank nun der Anspruch gestellt, das unterschiedliche Personen nur die jeweilig für sie relevanten Datensätze lesen und ggf. ändern können, quasi eine Art Mandatenfähigkeit. Mein bisheriger Ansatz das umzusetzen ist:

Ich kann die Datensätze soweit separieren, dass ich eine Extraspalte hinzufüge, mit Werten befülle (A,B,C) und so die Datensätze unterteile. Nun erstelle ich eine Extratabelle und hinterlege darin die Nutzernamen und packe sie in eine Gruppe (A,B,C). Mit einem kleinen Makro lese ich die Windowsbenutzernamen aus. Wenn nun der Nutzer Vaultboy das Accessfrontend startet, wird der Username ausgelesen. In der Tabelle ist er der Gruppe B zugeordnet und er darf nur die Datensätze lesen wo in der/den Extraspalte/n ein B steht.
Diesen Ansatz finde ich irgendwie mühselig, denn ich müsste meine ganzen Abfragen umsticken und mit einer Bedingung versehen. Ausserdem würde ich in der Benutzertabelle lieber nur AD-Gruppen pflege und die Berechtigungen kommen und gehen mit einer Gruppenänderung im AD.
Bin ich völlig auf dem Holzweg? Habt Ihr ne Idee wie man das besser/anders machen kann? Könnt Ihr mir helfen zumindest die AD-Gruppen-Anforderung zu lösen oder das ich nicht alle meine Abfragen umbauen muss?

Vielen Dank im vorraus für Eure Beiträge
Vaultboy

[tinof]

Moin,

ich würde das gleich auf dem Server machen und dem Frontend nur eine View 'unterschieben'.
Auf dem Server gibts' SESSION_USER / SYSTEM_USER usw (bitte hier mal danach suchen), dort steht der aktuelle Benutzer drin. Dann ich der Sicht gleich den Filter einbauen und im Accessfrontend nicht mehr drum kümmern.
Wäre auch sicherer, sollte jemand einmal die <F11> - Taste finden.

Aufpassen beim Einfügen von Datensätzen, dass diese ihr richtiges Kennzeichen (A/B/C) bekommen, sonst sind sie beim nächsten mal "weg"

Viel Erfolg
Tino

[Vaultboy]

Session_User kenne ich, nutze ich sogar schon in der gleichen DB zu anderen Zwecken. Aber bei der View habe ich ja das Problem des zurückschreibens. wie kann ich das umgehen?

[tinof]

Umgehen nicht, aber lösen:

a) per DEFAULT - Constraint - ist aber blöd, weil die "Gruppenzugehörigkeit" erst nachgeschlagen werden muß, evtl. über eine UDF

b) Im Insert/Update - Trigger der zugrundeliegenden Tabelle:

[highlight=sql]
...
UPDATE [tabelle] SET Mandant = {Mandant}
WHERE PrimaryKey IN (SELECT PrimaryKey FROM Inserted)
[/highlight]

Geht aber nur, wenn rekursive Trigger abgeschaltet sind, sonst gibt's eine Endlosschleife.

[Vaultboy]

möglichkeit a find ich gar nicht so schlecht, stehe aber auf dem schlauch was udf heißt *grübel*

b) der trigger muss dann aber auf der view liegen oder?

wie sieht es denn -auf beide optionen gesehen- mit der performance aus. welche ist schonender? Die Nutzeranzahl ist zwar noch recht überschaulich aber wer weiß, wer weiß....

[tinof]

:-) udf = user defined function

Aber Achtung - DEFAULT Einschränkungen greifen nur beim INSERT mit NULL in den betreffenden Spalten.

Nachtägliche Änderungen werden nicht mehr 'protokolliert'. Das kann gewünscht sein, oder aber nicht - dann benötigtst du zusätzlich den UPDATE - Trigger.

Einen Trigger würde ich direkt an die Tabelle hängen. Er 'feuert' auch, wenn die Aktualisierung über die Sicht ankommt.

Edit:
Performance
So oder so Kein Problem.
Trigger sind sowas von schnell, wenn der Code zur Ermittlung der jeweiligen einzutragenden Berechtigung nicht ganz schlecht ist merkt man da nix davon. Trigger sind u.a. ja genau für solche Dinge da. Ich finde sie generell übersichtlicher als DEFAULT - Werte, weil man da gleich mehrere Logiken gemeinsam / auf einen Blick pflegen kann.
Benutze aber auch ab und an beides in Kombination miteinander.