Im Mehrbenutzerbetrieb kommt es mitunter zur gleichzeitigen Bearbeitung eines Datensatzes durch mehrere Mitarbeiter. In diesem Fall brauchen Sie eine sinnvolle Strategie, um entweder das gleichzeitige ändern zu verhindern oder aber den Benutzern eine Hilfe zur Lösung von Schreibkonflikten an die Hand zu geben. Beides liefert der vorliegende Beitrag.
Wenn man vom Mehrbenutzerzugriff in Zusammenhang mit Access spricht, handelt es sich entweder um eine in Front- und Backend aufgeteilte Datenbank, deren Bestandteile jeweils als .mdb-Datei daherkommen oder um ein Access-Frontend, das seine Daten von einer SQL-Server-Datenbank bezieht. Dieser Beitrag beschränkt sich auf die zuerst genannte Variante und auf den Einsatz von Sperrmechanismen in Access-Formularen.
In der in diesem Beitrag zugrunde gelegten Konfiguration liegt das Backend auf einem Server, der von allen Rechnern mit der Frontend-Datenbank gut erreicht werden kann. Die Bearbeitung der Daten erfolgt außerdem ausschließlich über gebundene Formulare, andere Zugriffe wie etwa per DAO oder ADO werden nicht berücksichtigt.
Sperren von Datensätzen
Das Sperren von Datensätzen soll Inkonsistenzen von Daten verhindern, die durch das gleichzeitige ändern durch mehrere Bearbeiter entstehen. Ein Beispiel dafür ist der Lagerbestand eines Artikels, der gleichzeitig in zwei Bestellungen aufgenommen wird: Beide Bestellvorgänge gehen dabei von dem gleichen Lagerbestand aus und speichern jeweils den neuen Lagerbestand, der aus der Differenz der alten Anzahl und der bestellten Anzahl besteht. Dabei speichert das System das Ergebnis des Bearbeiters, der zuletzt auf OK geklickt hat.
Um dies zu verhindern, benötigt man Mechanismen, die frühestens beim öffnen des Datensatzes durch mehr als einen Benutzer und spätestens beim Schließen durch den zweiten Benutzer Alarm schlagen.
Sperrungsarten
Access unterstützt mehrere Sperrungsarten, die sich im Umfang der gesperrten Daten und im Auslösezeitpunkt des Mechanismus unterscheiden.
Für den Umfang der gesperrten Daten beim Bearbeiten eines Datensatzes gibt es folgende Varianten:
- Keine Sperrung
- Alle Datensätze der aktuellen Tabelle
- Speicherseite, in der sich der aktuelle Datensatz befindet (Jet speichert Daten immer in Blöcken á 4 Kilobyte; daher die Bezeichnung Speicherseite. Wie viele Datensätze vom Sperren einer Speicherseite betroffen sind, hängt von deren Felddatentypen und dem Inhalt ab)
- Nur der aktuelle Datensatz
Optimistisches Sperren
Der Auslösezeitpunkt hängt unmittelbar vom Umfang der Sperrung ab: Ohne Sperrung spricht man von optimistischer Sperrung, die wie folgt ausgelöst wird:
- Benutzer A öffnet einen Datensatz zum Bearbeiten.
- Benutzer B öffnet den gleichen Datensatz (oder je nach Sperrungsumfang einen Datensatz derselben Speicherseite oder derselben Tabelle).
- Benutzer A speichert den geänderten Datensatz.
- Benutzer B speichert den geänderten Datensatz.
Nun tritt ein Schreibkonflikt auf, weil Access feststellt, dass ein Datensatz gespeichert werden soll, dessen Anfangszustand nicht mit dem aktuellen Zustand übereinstimmt.
Für den Benutzer, der die letzte änderung speichern möchte, gibt es nun drei Möglichkeiten:
- Speichern seiner Version des Datensatzes,
- Kopieren seiner Version in die Zwischenablage, um diese nach Prüfung zu verwenden oder zu verwerfen oder
- Verwerfen der eigenen änderungen.
Pessimistisches Sperren
Wenn eine Sperrung im Formular aktiv ist, braucht der erste Benutzer den Datensatz nur zu öffnen, damit weitere Benutzer diesen Datensatz oder – falls Sperrung auf Seitenebene aktiviert ist – auch weitere Datensätze nicht mehr bearbeiten können.
Interessant ist hier der Zeitpunkt, zu dem die anderen Benutzer erfahren, dass sich ein Datensatz in Bearbeitung befindet: Dieser hängt nämlich vom Aktualisierungsintervall ab, das die Eigenschaft Anzeigeaktualisierungsintervall in den Access-Optionen festlegt. Sobald ein Benutzer den Wert eines Feldes verändert und damit die Feldeigenschaft auf “dirty” gesetzt hat, dauert es noch ein Weilchen, bis diese Information auf allen Rechnern, deren Access-Instanz ebenfalls diesen Datensatz anzeigt, erscheint. Je kleiner Sie dieses Intervall einstellen, desto mehr belastet dies natürlich das Netz.
|
Mit Sperrungen experimentieren |
|
Die in diesem Beitrag vorgestellten Techniken können Sie auch ohne die Aufteilung in Front- und Backend ausprobieren. Sie benötigen einfach nur eine Datenbank mit einer Beispieltabelle sowie zwei Formulare. Wenn Sie denselben Datensatz im ersten Formular und im zweiten Formular ändern und optimistisches Sperren aktiviert haben (also die Eigenschaft Datensätze sperren den Wert Keine Sperrungen aufweist), erhalten Sie denselben Effekt, als wenn Sie dies in zwei unabhängigen Frontends ausführen, die auf das gleiche Backend zugreifen. Beachten Sie aber, dass bei dieser Konfiguration einige Verzögerungen wegfallen, die beim Netzwerkbetrieb auftreten. |
Sperren im Formular
In Formularen entscheidet grundsätzlich die Eigenschaft Datensätze sperren über den anzuwendenden Sperrmechanismus (siehe Bild 1). Dabei wirkt sich die Einstellung Bearbeiteter Datensatz in Abhängigkeit von einer weiteren Eigenschaft unterschiedlich aus (ab Access 2000). Diese Eigenschaft legt man in den Access-Optionen unter Weitere/DB mit Sperrung auf Datensatzebene öffnen fest (siehe Bild 2). Nach dem Einstellen dieser Option müssen Sie die Anwendung zunächst erneut öffnen, danach sperrt Access entweder nur noch den aktuell bearbeiteten Datensatz oder die Speicherseite, die diesen Datensatz enthält (und damit gegebenenfalls auch andere Datensätze).
Bild 1: Einstellungen eines Formulars für die unterschiedlichen Arten der Datensatzsperrung
Bild 2:
Im Optionen-Dialog legen Sie fest, ob Sie Sperrungen auf Seiten- oder Datensatzebene verwenden möchten.
Unter Access 2007 finden Sie diese Einstellung übrigens in den Access-Optionen unter Erweitert/Erweitert/Datenbanken mit Sperrung auf Datensatzebene öffnen.
Benutzer führen
Die Access-Meldung, die beim Auftreten eines Schreibkonflikts auftritt, verunsichert manche Benutzer unter Umständen. Das ist aber kein Problem, denn Sie können den Schreibkonflikt genau wie Formularfehler abfangen und selbst behandeln.
Dazu legen Sie eine Prozedur für das Ereignis Bei Fehler des Formulars an und prüfen dort auf die Fehlernummer 7787. Dieser Fehler wird ausgelöst, wenn im aktuellen Formular ein geänderter Datensatz gespeichert werden soll, der in der Zwischenzeit von einem anderen Benutzer geändert wurde.
Nun brauchen Sie nur noch die Fehlermeldung aus Bild 3 durch eine eigene, geeignetere zu ersetzen. Aber müssen Sie das überhaupt
Bild 3: Dieser Dialog erscheint standardmäßig, wenn Access gleichzeitige änderungen eines Datensatzes durch mehr als einen Benutzer feststellt.
Wohl nur, wenn Sie zusätzlichen Komfort liefern möchten – beispielsweise, um die beiden Versionen des Datensatzes anzuzeigen und dem Benutzer somit eine bessere Entscheidungsgrundlage zu liefern.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo