Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 5/2009.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Zusammenfassung

Programmieren Sie eine Benutzerverwaltung für Ihre eigenen Anwendungen.

Techniken

Tabellen, Formulare, VBA

Voraussetzungen

Access 2000 und höher

Beispieldateien

Benutzerverwaltung.mdb

Shortlink

688

Benutzerverwaltung

André Minhorst, Duisburg

Bis Access 2003 unterstützte Access den Entwickler durch eine Benutzerverwaltung inklusive Sicherheitssystem. Neuere Access-Versionen bieten dies nicht mehr. Kein großes Problem: Das Sicherheitssystem war ohnehin nicht besonders effektiv, und die Benutzerverwaltung möchten Sie vielleicht ohnehin selbst gestalten. In diesem Beitrag zeigen wir, wie Sie eine solche Benutzerverwaltung selbst erstellen und einsetzen.

Unsere Benutzerverwaltung dient nicht als Ersatz für die bis Access 2003 verfügbare, eingebaute Benutzerverwaltung. Das darin enthaltene Sicherheitssystem werden wir nicht übernehmen. Der Grund ist einfach: Es ist schwierig, ein Sicherheitssystem zu implementieren, wenn die Datenbank-Engine keine Möglichkeiten für die Durchsetzung der dort festgelegten Regeln bietet. Dies ist zwar im SQL Server möglich und auch unter MySQL und anderen Systemen, aber die Jet Engine von Access bietet dies nicht - zumindest nicht offiziell. Intern ist ein Teil des Sicherheitssystems zwar noch vorhanden (das merken Sie, wenn Sie versuchen, Systemtabellen von Access zu verändern), aber es wird von Microsoft offiziell nicht mehr unterstützt. Das Unternehmen verfolgt damit wohl zwei Ziele: erstens die Abkehr vom unzuverlässigen Sicherheitssystem und zweitens die Nutzung von aktiven Datenbankmanagementsystemen mit »echter« Benutzerverwaltung.

In diesem Beitrag lassen wir den Sicherheitsaspekt weitgehend außer Acht - zumindest insofern, dass wir den direkten Zugriff auf Tabellen nicht unterbinden. Stattdessen konzentrieren wir uns darauf, Tabellen bereitzustellen, mit denen Sie Benutzer und Benutzergruppen erfassen können. Diese sollen über entsprechende Formulare gefüllt werden. Zusätzlich gibt es noch einen Anmeldedialog, über den der Benutzer sich mit Benutzername und gegebenenfalls einem Kennwort anmeldet. Diese Anmeldedaten der aktuellen Sitzung speichern wir an geeigneter Stelle und erstellen Funktionen, die für den angemeldeten Benutzer freigegebene Features ermitteln.

Einfache Variante

Im einfachsten Fall reicht für die Verwaltung von Benutzern eine Benutzertabelle aus. Sie würden darin lediglich Basisinformationen wie den realen Namen des Benutzers sowie seinen Benutzernamen und gegebenenfalls ein Kennwort speichern.

Was können Sie mit dieser Variante anfangen? Im Prinzip alles, was Sie auch mit einer um Benutzergruppen erweiterten Version erledigen können. Allerdings wird es dann kompliziert, wenn Sie viele Benutzer verwalten und für diese etwa festlegen möchten, welcher Benutzer welche Menübefehle ausführen oder Formulare öffnen darf: Hier kommt es oft vor, dass mehrere Benutzer die gleichen Berechtigungen erhalten sollen, was bei Verwendung von Benutzergruppen deutlich vereinfacht werden kann.

Wenn Sie die Benutzerverwaltung aber nur für individuelle, benutzerabhängige Aufgaben verwenden möchten, reicht eine einzige Benutzertabelle ohne Benutzerverwaltung völlig aus. Das Paradebeispiel hierfür ist das Protokollieren von Zugriffen auf und Änderungen an den Daten einer Datenbank. Dies geschieht immer in Abhängigkeit vom einzelnen Benutzer und erfordert somit nicht die Angabe seiner Benutzergruppe. Die hier verwendete Tabelle sieht beispielsweise wie in Abb. 1 aus. Beachten Sie, dass jeder Benutzername nur einmal vorkommen soll. Daher stellen Sie den Wert der Eigenschaft Indiziert für das Feld Benutzername auf den Wert Ja (Ohne Duplikate) ein.

pic002.png

Abb. 2: Diese Tabelle speichert unter anderem den angemeldeten Benutzer.

Wer Informationen in Abhängigkeit vom aktuell angemeldeten Benutzer speichern möchte, muss zunächst an geeigneter Stelle festhalten, welcher Benutzer gerade angemeldet ist. Dazu sind zwei Voraussetzungen notwendig:

  • Eine Tabelle, welche die ID des aktuellen Benutzers speichert.
  • Ein Formular, mit dem sich der Benutzer beim Start der Anwendung anmeldet.

Angemeldeten Benutzer merken

Die Tabelle zum Speichern des aktuell angemeldeten Benutzers soll eine einfache Optionen-Tabelle sein. Diese heißt tblOptionen und enthält die drei Felder OptionID (Autowert), Optionsname und Optionswert (beides Textfelder) und sieht im Entwurf wie in Abb. 2 aus.

pic001.png

Abb. 1: Entwurf der Tabelle zum Speichern von Benutzern

Unabhängig vom Formular, das die Anmeldung des Benutzers beim Anwendungsstart entgegennimmt, schreiben wir nun eine kleine Funktion, welche den Optionswert zu einem bestimmten Optionsnamen in dieser Tabelle speichert.

Dazu öffnen Sie den VBA-Editor (zum Beispiel mit der Tastenkombination Alt + F11) und wählen dort den Menübefehl Einfügen|Modul aus. Im nun erscheinenden Codefenster fügen Sie die Prozedur aus Listing 1 ein. Die Funktion rufen Sie wie folgt auf:

Listing 1: Mit dieser Funktion speichern Sie Optionen in der Tabelle tblOptionen.

Public Function OptionEinstellen(strOptionsname As String, strOptionswert As String) As Boolean

    Dim db As DAO.Database

    Set db = CurrentDb

    db.Execute "UPDATE tblOptionen SET Optionswert = '" & strOptionswert _

    & "' WHERE Optionsname = '" & strOptionsname & "'", dbFailOnError

    If db.RecordsAffected = 1 Then

        OptionEinstellen = True

        Exit Function

    Else

        If db.RecordsAffected > 1 Then

            db.Execute "DELETE FROM tblOptionen WHERE Optionsname = '" _

            & strOptionsname & "'", dbFailOnError

        End If

        db.Execute "INSERT INTO tblOptionen(Optionsname, Optionswert) VALUES('" & strOptionsname _

        & "', '" & strOptionswert & "')", dbFailOnError

        If db.RecordsAffected = 1 Then

            OptionEinstellen = True

            Exit Function

        End If

    End If

End Function

OptionEinstellen "CurrentUserID", 1

Die Funktion OptionEinstellen deklariert und instanziert ein Objekt des Typs Database mit einem Verweis auf die aktuelle Datenbank und verwendet dessen Execute-Methode, um SQL-Aktualisierungsabfragen aufzurufen. Davon gibt es zwei, von denen eine auf jeden Fall, eine weitere nach Bedarf aufgerufen wird. Die erste aktualisiert alle Datensätze der Tabelle tblOptionen, bei denen das Feld Optionsname den mit dem Parameter strOptionsname übergebenen Wert enthält und stellt für diese Datensätze den Inhalt von Optionswert auf den mit strOptionswert übergebenen Wert ein.

Die nachfolgende RecordAffected-Methode prüft, ob die Anzahl der durch diese Aktionsabfrage betroffenen Datensätze gleich eins ist - dies bedeutet, dass bereits ein Datensatz für die angegebene Option vorhanden war und dieser nun neu eingestellt wurde.

Liefert RecordsAffected einen anderen Wert als eins zurück, können zwei Probleme aufgetreten sein:

  • RecordsAffected hat einen Wert größer eins, was bedeutet, dass die Option bereits mehrfach angelegt wurde. Kein Problem: Die innerhalb der If...Then-Bedingung angegebene Aktionsabfrage löscht einfach alle Datensätze der Tabelle tblOptionen mit dem angegebenen Wert im Feld Optionsname - es soll nur einen Datensatz je Option geben, und der wird gleich neu angelegt.
  • Anderenfalls liefert RecordsAffected den Wert 0 zurück.

Erreicht die Prozedur die Zeile hinter der Zeile If db.RecordsAffected > 1 Then, ist auf keinen Fall mehr ein Optionsdatensatz mit dem angegebenen Optionsnamen mehr vorhanden, wodurch dieser gleich neu angelegt werden kann - und das erledigt die folgende INSERT INTO-Aktionsabfrage.

Formular zur Abfrage des Benutzers

Für den Moment gehen wir davon aus, das ein Formular zur Verwaltung von Benutzern vorhanden ist und dass bereits einige Benutzerdatensätze in der Tabelle tblBenutzer vorliegen (s. Abb. 3).

pic003.png

Abb. 3: Die Tabelle tblBenutzer mit einigen Beispieldaten

Darauf bauen wir nun ein Formular auf, dass als Anmeldeformular der Anwendung dienen soll. Das Formular soll im Wesentlichen zwei Textfelder zur Eingabe von Benutzername und Kennwort sowie eine Schaltfläche zum Abschließen der Eingabe enthalten. Das erste Textfeld heißt txtBenutzername, das zweite txtKennwort. Die Schaltfläche zum Abschließen der Eingabe heißt cmdLogin, und außerdem benötigen wir noch eine Schaltfläche zum Abbrechen des Logins namens cmdAbbrechen. Der Grobentwurf sieht erstmal so wie in Abb. 4 aus.

pic004.png

Abb. 4: Entwurf des Login-Formulars

Das normale Einloggen verläuft wie folgt: Der Benutzer gibt einen Benutzernamen und sein Kennwort ein und klickt auf die Login-Schaltfläche. Die dahinter verborgene Ereignisprozedur prüft, ob das Kennwort zum Benutzernamen stimmt, und trägt den neuen aktuellen Benutzer gegebenenfalls in die Optionen-Tabelle ein. Neben dieser Kombination aus gültigem Benutzernamen und passendem Kennwort gibt es jedoch noch weitere Varianten, die das Login-Formular berücksichtigen muss:

  • Der Benutzername ist vorhanden, aber das Kennwort ist falsch.
  • Der Benutzername ist nicht vorhanden.

In beiden Fällen soll der Benutzer eine Nachricht erhalten und erneut mit dem Login-Formular konfrontiert werden. Auch hier gibt es mehrere Möglichkeiten: Beide Textfelder behalten ihren Wert, beide Textfelder werden gelöscht oder der Benutzername wird beibehalten und nur das Kennwortfeld wird gelöscht - das ist der Fall, wenn der Benutzername richtig und das Kennwort falsch ist.

All dies wird zur blassen Theorie, denn wir arbeiten ja mit Access und wollen seine Mittel ausschöpfen. Die Benutzernamen der für die Anwendung registrierten Benutzer sind in der Tabelle tblBenutzer gespeichert. Warum sollte man den Benutzer also auf umständliche Weise seinen Benutzernamen eingeben lassen? Je nach der Konvention, die für die Zusammenstellung des Benutzernamens gewählt wurde (falls es denn eine gibt), kann es durchaus vorkommen, dass man seinen Benutzernamen einmal vergisst. Also werfen wir das Textfeld txtBenutzername raus, bevor wir richtig loslegen, und ersetzen es durch ein Kombinationsfeld namens cboBenutzername. Dieses passen wir durch Einstellen der folgenden Eigenschaften an:

  • Datensatzherkunft: SELECT Benutzername FROM tblBenutzer ORDER BY Benutzername
  • Spaltenanzahl: 1
  • Spaltenbreiten: leer

Auch das Textfeld txtKennwort zur Eingabe des Kennworts passen wir noch so an, dass die Kennworteingabe wie in einer professionellen Anwendung aussieht. Dort erscheinen statt des Kennworts im Klartext bei der Eingabe Platzhalter wie etwa das Sternchen (*). Diese Einstellung nehmen Sie vor, indem Sie die Eigenschaft Eingabeformat des Textfelds anklicken, die daraufhin erscheinende Schaltfläche mit den drei Punkten (...) betätigen und im Dialog aus Abb. 5 den Eintrag Kennwort auswählen.

pic005.png

Abb. 5: So sorgen Sie dafür, dass Dritte Kennwörter bei der Eingabe nicht mitlesen können.

Login bei Eingabetaste

Wenn der Benutzer auf einem Webformular die Eingabetaste drückt, bewirkt dies üblicherweise das Absenden der im Formular eingetragenen Daten. Dieses im Internet gängige Verhalten kann man auch beim Benutzer einer Datenbankanwendung als bekannt voraussetzen: Wenn dieser schon nicht mit der Maus von Eingabefeld zu Eingabefeld navigiert und die Eingabe mit einem Klick auf die entsprechende Schaltfläche abschließt, erledigt er dies in der Regel mit der Tabulator-Taste und schließt die Eingabe mit der Eingabetaste ab.

Dies soll auch hier der Fall sein. Ungeachtet der beim Abschließen der Anmeldung ausgeführten Codezeilen schauen wir uns erst einmal an, wie wir Access dazu bewegen, beim Klick auf die Eingabetaste das Gleiche zu tun wie beim Betätigen der Login-Schaltfläche. Dies verlangt nach Weniger, als Sie wahrscheinlich vermuten: Sie müssen lediglich die Eigenschaft Standard der Schaltfläche cmdLogin auf den Wert Ja einstellen.

Damit definieren Sie diese Schaltfläche als Standardschaltfläche des Formulars, die beim Klick auf die Eingabetaste automatisch ausgelöst wird. Das Gleiche ist übrigens auch für die Abbrechen-Schaltfläche möglich: Hier verwenden Sie allerdings die Eigenschaft Abbrechen der entsprechenden Schaltfläche, die Sie ebenfalls auf den Wert Ja einstellen. In diesem Fall führt das Betätigen der Escape-Taste zum Ausführen der für die Abbrechen-Schaltfläche hinterlegten Ereignisprozedur.

Beachten Sie aber, dass dies nicht funktioniert, wenn eine andere Schaltfläche bereits den Fokus besitzt, weil der Benutzer diese beispielsweise durch mehrfaches Betätigen der Tabulatortaste aktiviert hat.

Benutzername und Kennwort prüfen

Damit Sie das Verhalten der Schaltflächen und der damit verbundenen Tasten Enter und Escape prüfen können, legen Sie nun entsprechende Ereignisprozeduren für die Beim Klicken-Ereigniseigenschaften dieser Steuerelemente an.

Am einfachsten gelingt dies mit der Schaltfläche cmdAbbrechen: Diese soll bei Betätigung einfach die aktuelle Anwendung beenden, wenn der Benutzer sich nicht einloggen will oder kann. Sicherheitshalber soll die Anwendung den Benutzer noch fragen, ob dieser sicher ist, dass er die Anwendung beenden möchte. Dies sieht wie folgt aus:

Private Sub cmdAbbrechen_Click()

    If MsgBox("Dies beendet die Anwendung.

    Fortsetzen?", vbYesNo + vbExclamation,

    "Anwendung beenden") = vbYes Then

    DoCmd.Quit

End If

End Sub

Die Prozedur, welche die Benutzereingaben prüfen soll, fällt etwas länger, aber nicht komplizierter aus:

Private Sub cmdLogin_Click()

Dim lngBenutzerID As Long

lngBenutzerID = Nz(DLookup("BenutzerID", _

"tblBenutzer", "Benutzername = '" _

& Me!cboBenutzername _

& "' AND Kennwort = '" _

& Me!txtKennwort & "'"), 0)

If lngBenutzerID = 0 Then

MsgBox "Benutzername und/oder " _

    & "Kennwort sind falsch."

Else

MsgBox "Anmeldung erfolgreich!"

    OptionEinstellen "CurrentUserID", _

    CStr(lngBenutzerID)

    DoCmd.Close acForm, Me.Name

End If

End Sub

Die Routine verwendet die DLookup-Anweisung, um den Wert des Feldes BenutzerID für einen Datensatz der Tabelle tblBenutzer zu ermitteln, bei dem die Inhalte der Felder Benutzername und Kennwort mit den Inhalten der Textfelder txtBenutzername und txtKennwort übereinstimmen.

Wenn DLookup keinen passenden Datensatz findet, liefert es den Wert Null zurück - und dann tritt die Nz-Funktion auf den Plan, die den Wert Null durch den im zweiten Parameter angegebenen Wert ersetzt, in diesem Fall die Zahl 0. Diese wird schließlich in der Variablen lngCurrentUserID gespeichert.

Die nachfolgende If...Then-Bedingung prüft genau auf diesen Wert und verzweigt zu einer von zwei Möglichkeiten:

  • Ist der Wert von lngCurrentUserID 0, dann hat der Benutzer nicht die richtigen Daten eingegeben - es erscheint eine entsprechende Meldung und das Anmeldeformular bleibt sichtbar.
  • Ist der Wert ungleich 0, existiert der angegebene Benutzername samt Kennwort. Der Anmeldedialog wird geschlossen und die BenutzerID des aktuellen Benutzers im entsprechenden Datensatz der Tabelle tblBenutzer gespeichert.

Anzeigen des Loginformulars beim Start

Der Benutzer soll nach dem Start der Anwendung als Erstes das Loginformular sehen, damit er sich anmelden kann. Außerdem soll er nicht auf irgendein Element der Anwendung zugreifen können, bevor er sich nicht eingeloggt hat und das Loginformular geschlossen ist.

Das gelingt auf zwei Arten:

  • durch Einstellen bestimmter Eigenschaften des Formulars und Festlegen von frmLogin als Startformular der Anwendung in den Eigenschaften der aktuellen Datenbank.
  • durch Anlegen eines AutoExec-Makros mit einem Befehl zum Öffnen des Formulars als modalen Dialog.

Für die erste Variante zeigen Sie zunächst die Eigenschaften der aktuellen Datenbank an (unter Access 2003 mit dem Menübefehl Extras|Start, unter Access 2007 über die Schaltfläche Access-Optionen des Office-Menüs und anschließendes Wechseln in den Bereich Aktuelle Datenbank, s. Abb. 6). Dort wählen Sie für die Eigenschaft Formular anzeigen das Formular frmLogin aus.

pic006.png

Abb. 6: Einstellen eines Formulars als Startformular

Wenn Sie die Anwendung nun neu starten, erscheint das gewünschte Formular - aber der Benutzer kann ohne Eingabe der Logindaten auf die übrigen Elemente der Anwendung zugreifen und beispielsweise Tabellen öffnen.

Sie müssen das Formular noch als modalen Dialog auslegen und dies geschieht durch die folgenden beiden Schritte:

  • Einstellen der Eigenschaft Popup im Eigenschaftsfenster des Formulars auf Ja.
  • Einstellen der Eigenschaft Gebunden auf den Wert Ja.

Bei der zweiten Variante legen Sie zunächst ein neues Makro an und speichern es unter dem Namen AutoExec. Durch Verwendung dieses speziellen Namens wird es gleich beim Start der Anwendung ausgelöst - es sei denn, der Benutzer betätigt beim Starten die Umschalttaste. Legen Sie dann wie in Abb. 7 eine Aktion namens ÖffnenFormular an und legen Sie als Parameter den Formularnamen sowie als Fenstermodus den Wert Dialog fest. Dies erfüllt die gleiche Funktion wie das Einstellen der beiden Eigenschaften aus der vorherigen Variante.

Feinheiten

Sie müssen noch einige kleinere Anpassungen vornehmen:

  • Stellen Sie die Eigenschaften Mit Systemmenüfeld, Schließen-Schaltfläche und MinMax-Schaltfläche jeweils auf den Wert Nein ein, damit der Benutzer den Dialog nur über die beiden dafür vorgesehenen Schaltflächen verlassen kann.
  • Stellen Sie die Eigenschaften Datensatzmarkierer, Navigationsschaltflächen, Bildlaufleisten und Trennlinien auf den Wert Nein ein, damit störende Elemente ausgeblendet werden.
  • Stellen Sie den Text der Titelleiste des Formulars mit der Eigenschaft Beschriftung auf einen Wert wie Login oder Anmeldung ein.

Auch das Verhalten nach Eingabe falscher Benutzerdaten ändern wir noch: Da wir die Benutzernamen per Kombinationsfeld zur Auswahl bereitstellen, ist die Chance, dass der Benutzer einen falschen Namen auswählt, gering. Die Anmeldung wird also üblicherweise an der Eingabe des Kennwort scheitern. Damit der Benutzer nach einer Fehleingabe keine unnötigen Mimiken ausführen muss, legen wie den Fokus direkt auf das Textfeld txtKennwort, und zwar mit einer zusätzlichen Zeile in der Ereignisprozedur cmdLogin_Click:

[...]

If lngBenutzerID = 0 Then

MsgBox "Benutzername und/oder Kennwort sind falsch."

Me!txtKennwort.SetFocus

Else

[...]

Das Formular sieht in der Formularansicht nun wie in Abb. 8 aus.

pic007.png

Abb. 9: Entwurf der Tabelle tblBenutzergruppen

Benutzerverwaltung mit Benutzergruppen

Bevor wir uns ansehen, was wir mit dem angemeldeten Benutzer anstellen können, werfen wir noch einen Blick auf die Benutzergruppen. Deren Einrichtung ändert nichts am Login-Prozedere, aber wir brauchen diese später, um die Berechtigungen der Benutzer etwa für den Zugriff auf einzelne Elemente von Formularen auch auf Gruppenebene festlegen zu können.

Die Tabelle zum Speichern der Benutzergruppen heißt tblBenutzergruppen und enthält nur zwei Felder - BenutzergruppeID und Benutzergruppe. Letzteres versehen Sie mit einem eindeutigen Index, damit jede Benutzergruppe einen eindeutigen Namen besitzt (s. Abb. 9). Wie stellen wir aber nun die Beziehung zwischen den in der Tabelle tblBenutzer gespeicherten Benutzern und der Benutzergruppe aus tblBenutzergruppen her? Hier gibt es zwei Möglichkeiten, die davon abhängen, ob ein Benutzer nur einer oder mehreren Gruppen angehören darf. Wir wählen gleich die umfassendere Variante, indem wir über eine Verknüpfungstabelle namens tblBenutzerBenutzergruppen eine m:n-Beziehung zwischen den beiden Tabellen tblBenutzer und tblBenutzergruppen herstellen. Den Namen dieser Verknüpfungstabelle können Sie nach eigenem Gusto anpassen - sinnvoll wäre ebenso tblBenutzergruppenzuordnung. Nach einer in den meisten Lösungen von Access im Unternehmen verwendeten Konvention wäre die konsequente aber die erstgenannte, bei der dem Präfix tbl die beiden Objektarten der zu verknüpfenden Tabellen im Plural aufgeführt werden.

pic009.png

Abb. 7: Das AutoExec-Makro öffnet das Formular frmLogin als modalen Dialog.

pic008.png

Abb. 8: Das fertige Loginformular

Die Verknüpfungstabelle besteht aus drei Feldern: einem Primärschlüsselfeld namens ID als eindeutigem Index und den beiden Fremdschlüsselfeldern BenutzerID und BenutzergruppeID. Für diese beiden Felder legen Sie einen zusammengesetzten, eindeutigen Index fest (s. Abb. 10).

pic010.png

Abb. 10: Die Verknüpfungstabelle zur Herstellung der m:n-Beziehung zwischen Benutzern und Benutzergruppen

Damit für die beiden Felder BenutzerID und BenutzergruppeID nur solche Werte eingetragen werden können, die den Primärschlüsselfeldern der beiden Tabellen tblBenutzer und tblBenutzergruppen vorliegen, legen Sie erstens entsprechende Beziehungen zwischen den Tabellen an und aktivieren zweitens die Option Mit referentieller Integrität der Beziehungen. All dies geschieht im Beziehungen-Fenster, dass Sie über den Menüeintrag Extras|Beziehungen (Access 2003 und älter) beziehungsweise den Ribboneintrag Datenbanktools|Einblenden/Ausblenden|Beziehungen (Access 2007) öffnen. Stellen Sie für beide Beziehungen außerdem die Option Löschweitergabe an verwandte Datensätze ein. So gewährleisten Sie, dass beim Löschen etwa eines Benutzers auch die damit verbundenen Datensätze aus der Verknüpfungstabelle gelöscht werden (s. Abb. 12).

Verwalten von Benutzern und Benutzergruppen

Die Access-Versionen 2003 und älter stellten jeweils zwei Dialoge zum Anlegen und zur Zuordnung von Benutzern und Benutzergruppen bereit - einen, mit dem Sie einen Benutzer anlegen oder auswählen und diesem die entsprechenden Benutzergruppen zuweisen können, und umgekehrt. Es ist sicher praktisch, die Zuordnung von Benutzern und Benutzergruppen sowohl aus Sicht der Benutzer als auch aus Sicht der Benutzergruppen verwalten zu können, daher werden wir ebenfalls gleich zwei Formulare für diesen Zweck anlegen. Das erste heißt frmBenutzerBenutzergruppen und zeigt die Gruppenzugehörigkeit aus Sicht des Benutzers an. Es enthält die folgenden Steuerelemente (s. Abb. 12):

pic011.png

Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

Sind Sie Abonnent?Jetzt einloggen ...
 

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Verwandte Beiträge:

Änderungsdaten protokollieren

Access, MySQL und Berechtigungsverwaltung

Modale Dialoge mal anders

Formularposition speichern und wiederherstellen

Benutzer mit Access verwalten

Validieren mit Klasse

Meldungsfenster im Eigenbau

Kein Datensatz- und Positionswechsel bei Requery

Verschlüsselung und Komprimieren im Backend

Transparenz und andere Effekte in Formularen

Zugriff auf Formulare

Formulare für die Dateneingabe

Formulare im Blickpunkt

Individuelle Datenauswahl

Benutzerabhängige Befehlsleisten

Benutzereinstellungen verwalten

Performanter Webzugriff auf MySQL-Datenbanken

Unterformulare: Daten anlegen und löschen

Kontextmenüs von A bis Z

Von Access nach MySQL, Teil 2

Zuletzt verwendete Datensätze anzeigen

Sicherheitsfeatures in Access 2003

Projektzeitmanager

Daten visualisieren mit HTML

Auswahlfelder im Ribbon

Alphabetisches Register

Vertikale Menüleisten

Zoomfenster im Eigenbau

Access 2007: Sicherheitssystem einsetzen

Fortschrittsanzeige

Datenbank nach Vorlage

© 2003-2015 André Minhorst Alle Rechte vorbehalten.