Wenn Sie ein Abonnement des Magazins 'Access im Unternehmen' besitzen, können Sie sich anmelden und den kompletten Artikel lesen.
Anderenfalls können Sie das Abonnement hier im Shop erwerben.
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 ÄnderungenWenn 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 ÄndernWenn 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 anzulegenAnmeldung 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.
Dies war die Leseprobe dieses Artikels.
Melden Sie sich an, um auf den vollständigen Artikel zuzugreifen.