<\/p>\n
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.<\/b><\/p>\n<\/p><\/div>\n 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.<\/p>\n 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.<\/p>\n Sperren von Datensätzen<\/b><\/p>\n 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<\/b> geklickt hat.<\/p>\n 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.<\/p>\n Sperrungsarten<\/b><\/p>\n Access unterstützt mehrere Sperrungsarten, die sich im Umfang der gesperrten Daten und im Auslösezeitpunkt des Mechanismus unterscheiden.<\/p>\n Für den Umfang der gesperrten Daten beim Bearbeiten eines Datensatzes gibt es folgende Varianten:<\/p>\n Optimistisches Sperren<\/p>\n Der Auslösezeitpunkt hängt unmittelbar vom Umfang der Sperrung ab: Ohne Sperrung spricht man von optimistischer Sperrung, die wie folgt ausgelöst wird:<\/p>\n Nun tritt ein Schreibkonflikt auf, weil Access feststellt, dass ein Datensatz gespeichert werden soll, dessen Anfangszustand nicht mit dem aktuellen Zustand übereinstimmt.<\/p>\n Für den Benutzer, der die letzte änderung speichern möchte, gibt es nun drei Möglichkeiten:<\/p>\n Pessimistisches Sperren<\/b><\/p>\n 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.<\/p>\n 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 <\/b>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.<\/p>\n Mit Sperrungen experimentieren<\/p>\n<\/td>\n<\/tr>\n 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 <\/b>den Wert Keine Sperrungen <\/b>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.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/div>\n Sperren im Formular<\/b><\/p>\n In Formularen entscheidet grundsätzlich die Eigenschaft Datensätze sperren <\/b>über den anzuwendenden Sperrmechanismus (siehe Bild 1). Dabei wirkt sich die Einstellung Bearbeiteter Datensatz <\/b>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 <\/b>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).<\/p>\n Bild 1: Einstellungen eines Formulars für die unterschiedlichen Arten der Datensatzsperrung<\/span><\/b><\/p>\n<\/p><\/div>\n Bild 2: <\/p>\n Unter Access 2007 finden Sie diese Einstellung übrigens in den Access-Optionen unter Erweitert\/Erweitert\/Datenbanken mit Sperrung auf Datensatzebene öffnen<\/b>.<\/p>\n Benutzer führen<\/b><\/p>\n 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.<\/p>\n Dazu legen Sie eine Prozedur für das Ereignis Bei Fehler <\/b>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.<\/p>\n Nun brauchen Sie nur noch die Fehlermeldung aus Bild 3 durch eine eigene, geeignetere zu ersetzen. Aber müssen Sie das überhaupt<\/p>\n Bild 3: Dieser Dialog erscheint standardmäßig, wenn Access gleichzeitige änderungen eines Datensatzes durch mehr als einen Benutzer feststellt.<\/span><\/b><\/p>\n<\/p><\/div>\n 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.<\/p>\n Wenn Sie einmal ein einfaches Formular zur Anzeige der Artikel der Nordwind-Datenbank zugrunde legen, könnte dies wie folgt aussehen:<\/p>\n Zunächst fangen Sie den Schreibkonflikt in der Form_Error<\/b>-Prozedur ab. Dann öffnen Sie ein neues Formular, das die neue und die alte Version des Datensatzes nebeneinander anzeigt.<\/p>\n Zusätzlich weisen Sie den Benutzer mit einem Meldungsfenster darauf hin, dass es einen Schreibkonflikt gibt und er sich für seinen eigenen oder den Datensatz des anderen Benutzers entscheiden kann.<\/p>\n Je nach der Entscheidung des Benutzers behalten Sie entweder die vom zweiten Benutzer geänderte Version bei, was einfach ist, oder Sie übernehmen die änderungen des Benutzers des aktuellen Formulars – und das ist ein wenig komplizierter.<\/p>\n Wie das genau funktioniert, zeigt ein Blick auf den Code aus Listing 1.<\/p>\n Listing 1: Diese Routine wird beim gleichzeitigen ändern eines Datensatzes durch mehr als einen Benutzer ausgelöst und ermöglicht eine komfortable Konfliktlösung.<\/p>\n<\/td>\n<\/tr>\n Die erste Zeile sorgt dafür, dass parallel zum eigentlich angezeigten Formular bereits eine zweite Instanz des gleichen Formulars erzeugt, aber noch nicht angezeigt wird:<\/p>\n Die Routine, die durch das Ereignis Bei Fehler <\/b>ausgelöst wird, deklariert zunächst drei Variablen für ein Database<\/b>-, ein Recordset<\/b>– und ein Field<\/b>-Objekt.<\/p>\n Wozu Sie diese benötigen, erfahren Sie weiter unten. Danach folgt direkt die Select Case<\/b>-Anweisung, die zu der zur Fehlernummer passenden Bedingung verzweigt.<\/p>\n Falls der Fehler 7787, also eine änderung an einem gleichzeitig durch einen anderen Benutzer geänderten Datensatz, auftritt, zeigt die Routine die zweite Instanz des Artikel-Formulars an und springt per FindFirst<\/b>-Methode zum gleichen Datensatz, der auch im ersten Formular angezeigt wird. Der Titel dieses Formulars erhält einen aussagekräftigen Text („Geänderte Version des Artikels“) und das Formular wird rechts neben dem Originalformular platziert.<\/p>\n Zusätzlich erscheint eine Meldung, die den Benutzer dazu auffordert, entweder die eigene änderung oder die des anderen Benutzers zu übernehmen (siehe Bild 4).<\/p>\n Bild 4: Vergleich zweier parallel geänderter Datensätze und die Aufforderung, sich für eine Variante zu entscheiden<\/span><\/b><\/p>\n<\/p><\/div>\n Soll die änderung des anderen Benutzers gespeichert werden, ist nichts anderes zu tun als den Wert acDataErrAdded <\/b>mit dem Parameter Response <\/b>zurückzugeben.<\/p>\n Soll jedoch die änderung des aktuellen Benutzers gespeichert werden, wird es kompliziert:<\/p>\n Dummerweise bietet Access nämlich für den Response<\/b>-Parameter der Form_Error<\/b>-Prozedur nur die üblichen Werte an, und die stimmen nicht mit denen des standardmäßigen Dialogs aus Bild 3 überein. Im Detail sorgt der Wert acDataErrDisplay <\/b>nach wie vor dafür, dass Access die Standardfehlermeldung anzeigt, die Werte acDataErrAdded <\/b>und acDataErrContinue <\/b>sorgen beide für das übernehmen der änderungen des zweiten Benutzers.<\/p>\n Wie also nun die eigenen änderungen durchsetzen Dazu speichern Sie einfach den aktuellen Inhalt der gebundenen Steuerelemente des Formulars in einem Recordset, das die aktuelle (und damit die durch den anderen Benutzer geänderte) Version des Datensatzes enthält – fertig!<\/p>\n Hier ist noch nicht einmal besonders viel Schreibarbeit notwendig, denn man braucht einfach nur in einer For Each<\/b>-Schleife alle im Recordset enthaltenen Felder zu durchlaufen.<\/p>\n Und wenn das Formular nicht alle Felder der Tabelle anzeigt, dann bauen Sie das Recordset einfach auf einer Abfrage auf, die genau die im Formular enthaltenen Felder liefert.<\/p>\n Sperrungen rechtzeitig erkennen<\/b><\/p>\n Bei größeren änderungen würde es Sinn machen, gleichzeitig an einem Datensatz arbeitende Benutzer über ihre Aktivität zu unterrichten.<\/p>\n Bei der pessimistischen Sperrung ist das kein Problem: Hier beginnt der erste Benutzer mit der Bearbeitung und alle anderen gucken in die Röhre. Dumm wird es nur, wenn der aktuelle Bearbeiter des Datensatzes mittendrin beschließt, Mittagspause oder noch schlimmer Feierabend zu machen: läuft der Rechner weiter und ist der Datensatz in Bearbeitung, können die übrigen Mitarbeiter nicht darauf zugreifen.<\/p>\n Das lässt sich zwar auch durch den Einbau einer Timeout-Funktion umgehen, aber dies soll aus Platzgründen hier nicht beschrieben werden.<\/p>\n Zusammenfassung und Ausblick<\/b><\/p>\n Die Frage, ob Sie die optimistische oder pessimistische Sperrung verwenden, hängt ganz vom Einsatzzweck ab. Der Vorteil der optimistischen Sperrung liegt in der gegenüber der pessimistischen Variante geringeren Netzlast, da nicht immer alle anderen Benutzer informiert werden müssen, wenn ein Datensatz gesperrt ist – erst beim Speichern der änderungen eines Datensatzes erfolgt ein Abgleich mit der aktuell gespeicherten Version und ein eventueller Schreibkonflikt tritt auf.<\/p>\n In Anwendungen, bei denen jeder Benutzer ständig die aktuellen Informationen vorliegen haben muss, sind pessimistisches Locking und eine hohe Aktualisierungsfrequenz empfehlenswert – das bedeutet, dass Sie für regelmäßiges Speichern sorgen und verhindern müssen, dass Mitarbeiter einen offenen Datensatz über die Mittagspause liegen lassen.<\/p>\n Lassen Sie sich bei der Entscheidung für die richtige Locking-Strategie auf keinen Fall zur Annahme von Wahrscheinlichkeiten fehlleiten – die Aussage „Höchstwahrscheinlich greifen niemals zwei Mitarbeiter gleichzeitig auf den gleichen Kundendatensatz zu“ bedeutet letztlich: Es ist immer noch möglich, dass es zur gleichzeitigen Bearbeitung kommt.<\/p>\n Vielleicht können Sie ja sicherstellen, dass in der Tat der Mitarbeiter A nur die Kundendaten von A bis K und der Mitarbeiter B nur die Kundendaten von L bis Z bearbeitet beziehungsweise bearbeiten darf.<\/p>\n In dem Fall müssten Sie in Ihrer Anwendung zwar den jeweiligen Benutzernamen abfragen und nur die passenden Datensätze zur Bearbeitung freigeben, aber immerhin brauchen Sie sich so keine Gedanken über eventuelle Schreibkonflikte zu machen.<\/p>\n Falls doch, hängt es auch von den Fähigkeiten Ihrer Mitarbeiter ab, Schreibkonflikte mit den von Ihnen bereitgestellten Mitteln zu lösen: Klappt das, können Sie optimistisches Locking einsetzen, klappt es nicht, sollten Sie zum pessimistischen Locking greifen. <\/p>\n Das Locking von Daten spielt auch in DAO und ADO sowie bei ODBC-Verknüpfungen eine Rolle. Mehr darüber erfahren Sie den folgenden Ausgaben von Access im Unternehmen.<\/p>\n Enthaltene Beispieldateien:<\/p>\n Sperrungen.mdb<\/p>\n\n\n
\n
\n
\n\n\n
\n \n \n \n \n ![\"pic001.tif\"](\"..\/fileadmin\/_temp_\/2007_03\/Sperrungen-web-images\/pic001_opt.jpeg\")
\n <\/div>\n\n\n ![\"pic002.tif\"](\"..\/fileadmin\/_temp_\/2007_03\/Sperrungen-web-images\/pic002_opt.jpeg\")
\n <\/div>\n\n
Im Optionen-Dialog legen Sie fest, ob Sie Sperrungen auf Seiten- oder Datensatzebene verwenden möchten.<\/span><\/b><\/p>\n<\/p><\/div>\n\n ![\"pic003.tif\"](\"..\/fileadmin\/_temp_\/2007_03\/Sperrungen-web-images\/pic003_opt.jpeg\")
\n <\/div>\n\n\n\n\n
\n \n \n \n Dim frmKopie As New Form_frmArtikel<\/pre>\n
Private Sub Form_Error(DataErr As Integer, Response As Integer)<\/pre>\n
Dim db As DAO.Database<\/pre>\n
Dim rst As DAO.Recordset<\/pre>\n
Dim fld As DAO.Field<\/pre>\n
Select Case DataErr<\/pre>\n
Case 7787<\/pre>\n
With frmKopie<\/pre>\n
.Visible = True<\/pre>\n
.Caption = "Geänderte Version des Artikels"<\/pre>\n
.Recordset.FindFirst "ArtikelID = " & Me.ArtikelID<\/pre>\n
DoCmd.MoveSize Me.WindowLeft + Me.InsideWidth, Me.WindowTop<\/pre>\n
If MsgBox("Der Datensatz wurde von einem anderen Benutzer geändert. " _
& "Möchten Sie Ihre Version speichern und die andere Version verwerfen", _
vbOKCancel, "Schreibkonflikt") = vbOK Then<\/pre>\n Set db = CurrentDb<\/pre>\n
Set rst = db.OpenRecordset("SELECT * FROM tblArtikel WHERE ArtikelID = " _
& Me!ArtikelID, dbOpenDynaset)<\/pre>\n rst.Edit<\/pre>\n
For Each fld In rst.Fields<\/pre>\n
If fld.Name <> "ArtikelID" Then<\/pre>\n
rst(fld.Name) = Me(fld.Name)<\/pre>\n
End If<\/pre>\n
Next fld<\/pre>\n
rst.Update<\/pre>\n
Response = acDataErrContinue<\/pre>\n
Else<\/pre>\n
Response = acDataErrAdded<\/pre>\n
End If<\/pre>\n
frmKopie.Visible = False<\/pre>\n
End With<\/pre>\n
Case Else<\/pre>\n
Response = acDataErrDisplay<\/pre>\n
End Select<\/pre>\n
End Sub<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/div>\n
Dim frmKopie As New Form_frmArtikel<\/pre>\n
\n ![\"pic004.tif\"](\"..\/fileadmin\/_temp_\/2007_03\/Sperrungen-web-images\/pic004_opt.jpeg\")
\n <\/div>\n\nDownloads zu diesem Beitrag<\/h3>\n