Zugriffsrechte mit Datenmakros

Es gibt verschiedene Möglichkeiten, auf Basis des aktuell angemeldeten Benutzers sicherzustellen, dass dieser nur die für ihn vorgesehenen Aktionen mit Daten durchführen darf – beispielsweise durch eine Prüfung in den Ereignisprozeduren, die durch Ereignisse wie »Vor Aktualisierung« ausgelöst werden. Noch praktischer wäre es allerdings, wenn diese Prüfung nicht in jedem Formular programmiert werden müsste, sondern anwendungsweit verfügbar wäre – also auch dann, wenn der Benutzer es schafft, ohne Formulare auf die Tabellen mit den Daten zuzugreifen. Das gelingt mit Datenmakros. Wie genau, zeigt der vorliegende Beitrag.

Grundlage für unsere Beispielanwendung

Wenn wir Datenmakros für Tabellen programmieren wollen, die dafür sorgen, dass Benutzer abhängig von ihrer Benutzergruppe und den für diese vergebenen Berechtigungen auf den verschiedenen Tabellen Daten an den Tabellen ändern können, benötigen wir einige Tabellen, in denen wir die Berechtigungen speichern. In unserem Fall haben wir in den Beiträgen Benutzerverwaltung mit verschlüsselten Kennwörtern (www.access-im-unternehmen.de/1190) und Berechtigungen per HTML verwalten (www.access-im-unternehmen.de/1191) bereits einiges an Vorarbeit geleistet. Dort haben wir nämlich sowohl die Tabellen definiert, mit denen wir die Benutzer, Benutzergruppen, Tabellen und Berechtigungen sowie die Zuordnung der Berechtigungen zu den Kombinationen aus Benutzergruppen und Tabellen verwalten.

Ermitteln des aktuellen Benutzers

Um die Berechtigungen für den Zugriff auf eine Tabelle zu ermitteln, benötigen wir die Benutzerdaten. Darüber ermitteln wir die Benutzergruppe und schließlich die Berechtigung an der angegebenen Tabelle. Die Benutzerdaten haben wir im Beitrag Benutzer und Berechtigungen ermitteln (www.access-im-unternehmen.de/1192) nach der Anmeldung in einer temporären Variablen gespeichert. Das hilft in einem Datenmakro leider nicht weiter, denn von dort aus können wir nicht auf temporäre Variablen zugreifen. Also müssen wir die Prozedur im Formular frmAnmeldungen, welche die Benutzerdaten nach der Prüfung der Kombination aus Benutzername und Kennwort in temporären Variablen gespeichert hat, zunächst so ändern, dass die BenutzerID und der Benutzername in einer Tabelle landen – die in diesem Fall tblOptionen heißen soll. Die Prozedur cmdAnmelden_Click ändern wir dazu wie in Listing 1. Die Prozedur trägt zunächst den Benutzernamen aus dem Textfeld txtBenutzername in die Variable strBenutzername ein. Dann prüft sie mit der Funktion AnmeldungPruefen, ob die Anmeldedaten korrekt sind. Ist dies der Fall, ermittelt sie per DLookup den Wert des Feldes BenutzerID für den angegebenen Benutzernamen und speichert diesen in der Variablen lngBenutzerID.

Private Sub cmdAnmelden_Click()

     Dim db As DAO.Database

     Dim strBenutzername As String

     Dim lngBenutzerID As Long

     Set db = CurrentDb

     strBenutzername = Nz(Me!txtBenutzername, "")

     If AnmeldungPruefen(strBenutzername, Nz(Me!txtKennwort, "")) = True Then

         lngBenutzerID = DLookup("BenutzerID", "tblBenutzer", "Benutzername = '" & strBenutzername & "'")

         db.Execute "UPDATE tblOptionen SET Benutzername = '" & strBenutzername & "', BenutzerID = " & lngBenutzerID, _

             dbFailOnError

         If db.RecordsAffected = 0 Then

             db.Execute "INSERT INTO tblOptionen(Benutzername, BenutzerID) VALUES('" & strBenutzername & "', " _

                 & lngBenutzerID & ")", dbFailOnError

         End If

         DoCmd.Close acForm, Me.Name

     Else

         MsgBox "Anmeldung nicht erfolgreich."

         db.Execute "INSERT INTO tblOptionen(Benutzername, BenutzerID) VALUES("", 0)", dbFailOnError

         If db.RecordsAffected = 0 Then

             db.Execute "UPDATE tblOptionen SET Benutzername = '' AND BenutzerID = 0", dbFailOnError

         End If

     End If

End Sub

Listing 1: Prozedur zum Speichern der Daten nach der Anmeldung in der Tabelle tblOptionen

Damit versucht sie, die beiden Felder Benutzername und BenutzerID in der Tabelle tblOptionen durch den Aufruf einer UPDATE-Anweisung auf die neuen Werte zu aktualisieren. Ob das gelungen ist, zeigt die Eigenschaft RecordsAffected im Anschluss. Liefert sie den Wert 0, wurde kein Datensatz geändert, was nur bedeuten kann, dass noch kein Datensatz vorhanden ist. In diesem Fall ruft die Prozedur eine INSERT INTO-Anweisung auf und fügt einen neuen Datensatz mit den gewünschten Werten zur Tabelle tblOptionen hinzu.

Sollte die Funktion AnmeldungPruefen den Wert False zurückgeliefert haben, füllt die Prozedur auf die gleiche Art das Feld BenutzerID mit dem Wert 0 und Benutzername mit einer leeren Zeichenkette.

Ändern per Datenmakro unterbinden

Wenn wir etwa das Ändern der Daten eines Datensatzes unterbinden wollen, können wir das durch ein ganz einfaches Datenmakro erledigen. Wir schauen uns das am Beispiel der Tabelle tblKunden an, für die wir Änderungen zunächst komplett verhindern wollen. Dazu legen wir ein Datenmakro an, indem wir bei in der Datenblattansicht geöffneter Tabelle den Ribbon-Eintrag Tabelle|Vorabereignisse|Vor Änderung anklicken (siehe Bild 1).

Bild 1: Anlegen eines Datenmakros per Ribbon-Befehl

Das öffnet den Makro-Editor für dieses Makro, dem wir nur eine einzige Makro-Aktion hinzufügen (siehe Bild 2). Diese enthält den Befehl AuslösenFehler mit der Nummer 1 und dem Text Ändern nicht möglich als Fehlerbeschreibung.

Bild 2: Einfaches Makro zum Unterbinden von Änderungen

Wenn Sie nun den Makro-Editor schließen und versuchen, einen der Datensätze der Tabelle tblKunden zu ändern, erhalten Sie beim Speichern die Meldung aus Bild 3. Ein ähnliches Datenmakro können Sie für das Ereignis Vor Löschung anlegen – in diesem Fall mit einer entsprechenden Fehlermeldung wie Löschen nicht möglich. Wenn Sie nun versuchen, einen der Datensätze zu löschen, wird das ebenfalls nicht gelingen.

Bild 3: Meldung beim Versuch, einen Datensatz zu ändern

Was aber geschieht, wenn wir einen neuen Datensatz anlegen möchten? Dann erscheint die gleiche Meldung wie beim Versuch, den Datensatz zu ändern. Hier müssen wir also noch differenzieren. Das erledigen wir im Datenmakro für das Ereignis Vor Änderung, indem wir eine Wenn-Bedingung hinzufügen, für die wir die Bedingung IstNull([Alt].[KundeID]) festlegen (siehe Bild 4). Alt enthält ein Recordset mit den Daten des Datensatzes vor dem Ändern. Bei einem vorhandenen Datensatz liefert KundeID den zwangsläufig vorhandenen Primärschlüsselwert, beim Anlegen eines neuen Datensatzes ist [Alt].[KundeID] leer, als NULL.

Bild 4: Unterscheidung von neuen und vorhandenen Datensätzen beim Ändern

Wenn dies der Fall ist, soll das Makro die Meldung Anlegen nicht möglich ausgeben, sonst Ändern nicht möglich (siehe Bild 5).

Bild 5: Meldung beim Versuch, einen neuen Datensatz anzulegen

Anmeldung prüfen

Damit kommen wir zu dem Punkt, wo wir die Meldungen nur in Abhängigkeit von den Berechtigungen des Benutzers an der jeweiligen Tabelle anzeigen wollen.