Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.
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.
Wenn also etwa ein Benutzer angemeldet ist, der Daten der Tabelle tblKunden anlegen und ändern, diese aber nicht löschen darf, soll nur das Löschen von Datensätzen unterbunden werden.
Abfrage zum Ermitteln der Berechtigung
Da wir nun die Daten des aktuellen Benutzers in einer Tabelle namens tblOptionen speichern und diese auch den Wert des Primärschlüsselfeldes des angemeldeten Benutzers enthält, können wir eine Abfrage erstellen, welche diese Daten der Tabelle tblOptionen nutzt. Dazu fügen wir dieser Abfrage, die wir unter dem Namen qryTabellenberechtigungen speichern wollen, die Tabellen aus Bild 6 hinzu.
Bild 6: Abfrage zum Ermitteln der Berechtigungen
Hier sehen Sie auch, dass wir nur zwei Felder zum Entwurfsraster hinzufügen, nämlich Tabelle und BerechtigungID. Das reicht aus, um zu ermitteln, ob der aktuelle Benutzer eine bestimmte Berechtigung für eine Tabelle hat. Den aktuellen Benutzer ermitteln wir ja bereits über die Tabelle tblOptionen, daher müssen wir die Daten der Abfrage nur noch nach dem Namen der zu untersuchenden Tabelle und der zu berücksichtigenden Berechtigung filtern.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
Testzugang
eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel
diesen und alle anderen Artikel mit dem Jahresabo