Microsoft Access: Datenbank angeblich durch anderen Benutzer gesperrt

Eine Microsoft Access-Datenbank wird von mehreren Benutzern über das Netzwerk ausgeführt und es kommt bei diesen sporadisch zu Fehlermeldungen wie „Datei konnte nicht gesperrt werden“, „XYZ.accdb konnte nicht verwendet werden, Datei wird bereits verwendet“ oder „Datenbank ist durch XYZ gesperrt“? Ebenfalls kann auch eine Meldung wie „Das Microsoft Access-Datenbankmodul hat den Vorgang angehalten, da Sie und ein weiterer Benutzer gleichzeitig versuchen, dieselben Daten zu ändern“ auftauchen. Wie man diese Probleme lösen kann erfährst du im folgenden Artikel.

Mehrbenutzer-Betrieb über ein Netzlaufwerk

Im Regelfall legt man eine Access-Datei der Bequemlichkeit halber auf einem Netzlaufwerk ab. Denn meistens nutzen verschiedene Benutzer gleichzeitig diese eine Datei. Diese legt man dann in einen Ordner, auf den nur die Benutzer Zugriff haben, die diese Datei auch verwenden sollen.

Wenn die Benutzer sonst keine Dateien in dem Ordner ablegen oder verändern sollen, könnte man auch auf die Idee kommen, diesen die Schreibrechte lediglich für die Access-Datei zu gewähren. Dies sähe in den Sicherheitseinstellungen des Netzlaufwerks und der Access-Datei z. B. wie folgt aus:

Der Nutzer „access-test“ hat in diesem Fall keinen Schreibzugriff auf das Netzlaufwerk Z:, jedoch auf die dort befindliche Datei „Database.accdb“. Dadurch können seine Änderungen in die Tabellen der Datei übernommen werden. Zumindest in der Theorie ist dies eine nette Idee um die Benutzerrechte möglichst stark einzuschränken.

 

Probleme

Von diesem Netzwerkordner aus öffnen dann normalerweise viele Leute gleichzeitig diese Access-Datei.
Hierdurch ergibt sich dann oftmals ein unregelmäßig auftretendes Problem. Es wird dann eventuell gemeldet, dass die Datenbank bereits durch einen anderen PC gesperrt ist oder nicht gesperrt werden kann, sobald jemand die Datei öffnet.

Die Meldung könnte z. B. so lauten:

„Datenbank ist durch XYZ gesperrt“

Es können allerdings auch vielfältige andere Meldungen auftreten. Diese sind vermutlich auch von der eingesetzten Access-Version und den geätigten Einstellungen in Access und den vergegebenen Benutzerrechten abhängig sind.

 

Keine Schreibrechte auf dem Netzwerkpfad

Wenn dem Nutzer die Rechte auf den kompletten Pfad zum Schreiben fehlen bekommt er logischerweise folgende Meldung bzgl. eines Schreibschutzes:

Allerdings bekommen, wenn der Nutzer ohne Rechte die Datei geöffnet hat, auch Nutzer mit Schreibrechten diese Meldung und können nichts mehr machen!

 

Schreibrechte nur für die Access-Datei vergeben

Wenn man die Schreibrechte nur für die Access-Datei mit der Endung „accdb“ eingerichtet hat, gibt es trotzdem ein gravierendes Problem. Beim Öffnen dieser Datei legt Access nämlich standardmäßig auch eine temporäre Sitzungsdatei mit der Endung „laccdb“ an. In dieser werden die zugreifenden Computer/Benutzer erfasst. Die Erstellung bzw. das Schreiben in diese Datei ist allerdings nicht möglich, wenn die Schreibrechte auf den restlichen Inhalt des Ordners fehlen. Eine Vergabe der Rechte auch für diese Datei ist nicht wirklich möglich, da die Datei nur temporär ist und immer wieder gelöscht wird, sobald alle Benutzer Access geschlossen haben.

Wenn diese „laccdb“-Datei nicht erstellt werden kann, kommt es logischerweise zu Zugriffsproblemen. Ist die Access-Datei bereits bei einem Nutzer mit ausreichenden Rechte für die laccdb-Datei geöffnet, so erhält man die Meldung „Datei konnte nicht gesperrt werden“.

Hat kein anderer Benutzer die Datei offen wird zwar die Datei geöffnet, aber nur im schreibgeschützten Modus. Dann können ebenfalls andere Nutzer mit ausreichenden Rechten die Datei nicht bearbeiten.

Was die Rechte betrifft, müssten alle User wirklich volle Schreibrechte auf den Ordner bekommen, der die accdb-Datei enthält und nicht nur auf die accdb-Datei selber.

 

Exklusive Sperrung aktiviert?

Wenn die „exklusive Sperrung“ aktiviert ist, erstellt Access keine laccdb-Datei beim Öffnen der accdb-Datei. Die Datei kann man so auch öffnen und speichern, wenn der eigene Account nur Schreibrechte für die accdb-Datei hat. In diesem Fall wären die Rechte dafür ausreichend. Die Schreibrechte werden dann nicht für den gesamten Ordner benötigt. Aber für andere Nutzer ist das Öffnen aufgrund der exklusiven Sperre natürlich nicht mehr möglich. Zumindest bis der erste Nutzer die Datei wieder schließt erscheint bei anderen Nutzern dann diese Meldung:

Diese „exklusive Sperre“ sollte man deshalb für Dateien, die mit mehreren Benutzern gleichzeitig genutzt werden sollen, grundsätzlich immer deaktiviert lassen. Man findet den Menüpunkt in den Clienteinstellungen unter „Standardöffnungsmodus“. Hier ist „Freigegeben“ auszuwählen:

 

Ursache

Die wohl häufigste Ursache für dieses Problem ist eben die Nutzung einer einzigen Access-Datei in einem Netzwerkordner. Diese enthält sowohl das Backend (die Datenbank) wie auch das Frontend. In Kombination mit restriktiven Berechtigungen und einer ungünstigen Konfiguration der Access-Datei kann dies zu den diversen Fehlern führen.

Mit Frontend ist die Eingabemaske bzw. das Formular gemeint, welches die Daten aus der Datenbank anzeigt bzw. manipuliert. Das kann z.B. eine solche einfache Maske sein:

 

Lösung

Die reine Datenbank-Access-Datei bzw. das Backend, das nur die Tabellen enthält, legt man auf dem Netzwerkshare ab und es ist von dort aus für alle Benutzer zugänglich. Die Frontend-Access-Datei legt man am besten bei jedem Benutzer lokal auf dem Computer ab und nur von dort aus darf diese von ihm geöffnet werden!

Tipp: Grundsätzlich ist auch das Ausführen von Programmen (exe-Dateien) von einem Netzlaufwerk schon nicht empfehlenswert, auch wenn ich es oft gesehen habe und auch selber umsetzen musste. Wenn allerdings eine Access-Datei nur als einfache Tabelle verwendet wird und keinerlei Formulare oder dergleichen eingearbeitet wurden, dann sollte der Zugriff auch mit mehreren Benutzern gleichzeitig funktionieren!

Eine vorhandene Access-Datei kann man manuell oder mit Hilfe des Assistenten in Back- und Frontend aufteilen. Den Assistent findet man in aktuellen Access-Versionen unter „Datenbanktools“:

Man legt die Datenbank als Backend-Datei ab. Die aktuell geöffnete Datei enthält danach nur noch Verweise zur Backend-Datei.

Man kann das Ganze auch manuell vornehmen, wenn man sich gerne unnötige Arbeit macht. Der Vollständigkeit halber folgt hier auch eine Anleitung dafür. Um es sich dabei einfach zu machen, kopiert man am besten die ursprüngliche Access-Datei und benennt diese in eindeutige Namen für Back- und Frontend um.

 

Anpassung der Backend-Datei:

In der Backend-Datei löscht man bis auf die Tabellen alle anderen Inhalte heraus. Diese Datei kommt dann mit Lese- und Schreibrechten für die Benutzer auf das Netzlaufwerk.

 

Anpassung der Frontend-Datei:

In der Frontend-Datei schmeißt man nun die Tabellen einfach alle weg. Dies kann man einfach über das Kontextmenü per Rechtsklick auf die Tabellen durchführen. Die Warnmeldungen bzgl. der Entfernung der Tabelle kann man dann einfach bejahen:

Über den Reiter „Externe Daten“ kann man dann die Backenddatei auf dem Netzlaufwerk als Quelle angeben:

An dieser Stelle ist es ganz wichtig, dass man in dem Assistenten die „Verknüpfung zur Datenquelle“ wählt und nicht die Tabellen wieder importiert und im Frontend mit abspeichert:

Danach kann man alle Tabellen auswählen, die man übernehmen und mit dem Frontend „verknüpfen“ möchte:

Danach kann man in der Frontend-Datei auch sehen, dass die Tabellen nur verknüpft sind. Dazu muss man nur mit dem Cursor auf einer Tabelle stehen bleiben. Dann wird einem der Pfad zur Backend-Datei angezeigt:

 

Update der Access-Frontend-Dateien

Das zuvor aufgezeigte falsche Vorgehen mit der Ablage auf dem Netzlaufwerk wird, sowohl bei den Access-Modulen wie auch bei exe-Dateien gerne gemacht, um bei Updates nur eine Datei tauschen zu müssen. Ansonsten müsste man auf jedem einzelnen Endanwender-PC die aktuelle Datei abglegen.

 

Update auf dem Netzlaufwerk

Das Nutzen über das Netzlaufwerk hat aber auch gravierende Nachteile, wenn die zu atuschende Datei grad im Zugriff ist. Ein Austauschen ist beispielsweise nicht möglich, während auch nur ein einziger Benutzer diese Datei noch geöffnet hat. Das ist insbesondere dann ganz toll, wenn während des normalen Arbeitstages die Datei ausgetauscht werden muss. Das habe ich, bei auf Netzlaufwerken abgelegten exe-Dateien, sehr oft machen müssen wenn ein Softwarehersteller eine neue Programmversion kurzfristig für eine Fehlerkorrektur übergeben hat. Viel gewonnen hat man dann nicht, wenn man alle Benutzer aus ihrer Sitzung schmeißen muss oder erst einmal nachhaken muss ob diese ihre Arbeit kurzfristig unterbrechen können.

 

Update auf lokalen Arbeitsplätzen

Stattdessen ist es eigentlich immer zu empfehlen die auszuführenden Dateien lokal auf dem Client-Rechner liegen zu haben und dort auszuführen. Hier muss man sich eventuell eine Deployment-Strategie überlegen, damit die aktuelle Frontend-Datei nach einer Anpassung auch alle Benutzer erreicht. Diesen einfach nur zu schreiben, dass sie die Datei selber austauschen sollen führt oft zu Problemen. Meistens kommt mindestens eine Person der Bitte nicht nach und schiebt es auf die lange Bank.

Dies könnte man über eine Softwareverteilung oder auch, ohne ein großes Fass aufzumachen, durch eine Batchdatei regeln. Diese öffnet der Benutzer dann statt der Access-Datei. Sie prüft dann vor dem Start der Access-Datei immer auf die aktuelle Version und kopiert diese gegebenenfalls.

Das könnte z. B. in einer wirklich einfachen Ausführung so aussehen:

 

Natürlich ist es unschön, wenn ein CMD-Fenster bei Ausführung durch einen unwissenden Benutzer sichtbar wird und er die „Hieroglyphen“ der Command-Line zu sehen bekommt. Noch schlimmer ist es allerdings wenn ein etwas versierterer Benutzer dieses zu sehen bekommt und er auf „falsche Gedanken“ kommt und damit herumbastelt.

Um dies zu unterbinden könnte man das Batch- oder Powershell-Skript auch in eine ausführbare Exe-Datei umwandeln und minimiert ausführen. So kann der Endanwender sich auch den Code nicht ansehen.

Eine weitere Alternative bietet die recht einfach zu nutzende Programmiersprache „AutoIt“. Hier ist es ebenfalls möglich eine solche Update-Routine umzusetzen und das ganze direkt als exe-Datei abzulegen, die dem Benutzer nicht offenlegt was im Hintergrund passiert.

 

Probleme während Datensatzänderungen

In einer Access-Datenbank wollte ich mit einer einfachen SQL-Abfrage in jedem Eintrag der Datenbank den Inhalt eines Feldes löschen. Die Abfrage sah ungefähr so aus:

Leider kam bei jedem Versuch die folgende Fehlermeldung:

Das Microsoft Access-Datenbankmodul hat den Vorgang angehalten, da Sie und ein weiterer Benutzer gleichzeitig versuchen, dieselben Daten zu ändern.

Natürlich war dem nicht so und auch bei mir hatte ich die betroffenen Tabelle nicht mehr geöffnet.

 

Lösung

Nach ein bisschen herumprobieren und mehrmaligem Neuöffnen der betroffenen Datei hat bei mir nur folgendes funktioniert:

Die Access-Datei unter einem neuen Namen als Kopie abspeichern!

Wenn man diese Kopie dann öffnet, lässt sich in dieser die SQL-Abfrage ohne Probleme abfeuern.

Um die Datenbankdatei um unnötige Daten zu erleichtern, die sich in Form von Bilddateien in einem MEMO-Feld befanden, habe ich dann die Funktion „Datenbank komprimieren und reparieren“ verwendet. Danach fand ich in der Access-Datei auch einen „Fehlereintrag“ bzw. eine „Fehlertabelle“ namens „MSysCompactError“, die meiner Vermutung nach auch etwas mit der fehlerhaften Sperre eines bestimmten Datensatzes zu tun gehabt haben könnte.

 

 

Fazit

Microsoft Access ist durchaus ein nettes Tool, um als Ergänzung zu Excel schnell eine eigene Datenbank zu erstellen. Sogar ein Formular als Frontend für einen Endanwender kann man relativ einfach bereitstellen. Insbesondere als Systemadministrator kann man damit schnell mal etwas umsetzen, wie zum Beispiel eine Mitarbeiterverwaltung oder dergleichen, um beim Chef zu glänzen. Zwar kann man es für einen richtigen Multi-User-Betrieb benutzen, muss jedoch mit Problemen rechnen und genau wissen was man tut. So kann es zum Beispiel passieren, dass „die Datenbank durch einen anderen Benutzer gesperrt ist“. Allerdings wäre genügend Hintergrundwissen natürlich auch dann nötig, wenn man eine „richtige“ Datenbank und ein selbst programmiertes Frontend für diese nutzt.

Natürlich kann man es mit 100 Nutzern parallel benutzen, aber das ist meiner Meinung nach einfach keine „ideale“ Lösung, auch wenn ich genau solche Anwendungsfälle schon in der Praxis erlebt habe. Es gab oder gibt ja auch durchaus Firmen die Software komplett in Access umsetzen und sogar verkaufen. Solange man die Trennung in Back- und Frontend berücksichtigt und ein funktionierendes Update-Prozedere umsetzt, finde ich es allerdings auch nicht in Ordnung Access als mögliche Lösung für ein paar Mitarbeiter völlig zu zerreißen, so wie es im Internet viele Leute praktizieren.