Warum DropBox, OneDrive und Offline-Ordner deine Access Datenbank zerstören

von Philipp Stiefel, ursprünglich veröffentlicht am 9. Mai 2017

Basierend auf einem Foto von Willi Heidelbach, hier verwendet unter CC0 Lizensierung

Ab und zu lese ich Fragen in Microsoft Access Foren, wie man eine Access Datenbank mit anderen Benutzern auf DropBox, Onedrive oder einem Windows Offline-Ordner teilen kann. Das ist tatsächliche eine sehr einfache Frage mit einer einfachen Antwort.

Die kurze und einfache Antwort ist: Tu . das . nicht!

Gut, wenn dir diese Antwort ausreicht, dann sind wir hier fertig. – Du kannst gerne noch ein paar andere Artikel auf meiner Seite lesen. ;-)

Oh, ok, ….

…du bist immer noch hier. Dann werde ich dich nicht verblüfft mit dieser einfachen Antwort zurücklassen. Du bist ja offensichtlich interessiert, die Hintergründe zu erfahren. Also solltest du hier weiterlesen.

Das Problem lässt sich auf Datenbank-Korruption und Datenverlust zurückführen.

Einfache Synchronisationslogik

Die Synchronisationslogik von OneDrive-, DropBox-Ordnern versucht die zuletzt geänderte Version einer jeden Datei zu synchronisieren, die es dem lokalen Offline-Ordner findet. Der einfachste Indikator um die zuletzt geänderte Version einer Datei zu finden, ist das Änderungsdatum der Datei. Das funktioniert gut, wenn du die einzige Person bist, die mit einer bestimmten Datei arbeitet und wenn du immer den letzten Stand der Datei mit dem zentralen Speicherort, dem OneDrive-, DropBox oder Datei-Server synchronisierst, nachdem du die Datei irgendwo geändert hast. Das ist einfach und funktioniert mit jeder Art von Datei.

Fortgeschrittene Synchronisationsmagie

Du magst festgestellt haben, dass es ein paar Anwendungen gibt, die in der Lage sind sogar konkurrierende Änderungen an einer Datei zu behandelt. OneNote ist ein bemerkenswertes Beispiel einer solchen Anwendung. Ich bin immer wieder positiv überrascht, gut OneNote dies behandeln kann. Manchmal arbeite ich mit anderen Leuten in einem OneNote-Notizbuch, das auf OneDrive liegt. Wenn ich online arbeite, tauchen die Änderungen von anderen Benutzern direkt auf der Seite, die ich gerade betrachte, automatisch aus dem Nichts auf. Das ist so verblüffend. Ich kann mich nur an ein oder zwei Situationen in den letzten 5 Jahren erinnern, in denen OneNote eine Fehlermeldung angezeigt hat, dass es wegen Konflikten oder einem ähnlichen Grund nicht in der Lage ist Änderungen zu synchronisieren.

Allerdings solltest du dir bewusst sein, dass dies nicht durch eine geheime Magie, die in die Synchronisationslogik von OneDrive eingebaut ist. Die Grundlagen für diese Synchronisierung ist in das OneNote-Dateiformat und in die verschiedenen OneNote-Anwendungen eingebaut. Dies ist also eine Ausnahme. Du solltest solche Fähigkeiten nicht auch von anderen Anwendungen erwarten.

Probleme mit Access Dateien

Jetzt, wo wir wissen, dass die Synchronisierungsmöglichkeiten von der Anwendung und ihrem Dateiformat abhängig sind, lass uns Access und sein Dateiformat betrachten.

Das Datenbank-Dateiformat

Das Access Dateiformat wurde zu einer Zeit entwickelt, bevor irgendjemand über Offline-Dateisynchronisation irgendeiner Art nachgedacht hat. Selbst wenn damals jemand daran gedacht hat, war es eine gute Entscheidung, alle Ambitionen für Offline-Synchronisierung in das Access-Dateiformat einzubauen, fallenzulassen. Jede Datenbank profitiert von einem sehr dichten, binären Dateiformat, das so wenig Festplattenzugriffe wie möglich benötigt, um die größtmögliche Menge an Nutzdaten zu lesen.

Außerdem unterscheiden sich Datenbankdateien von den meisten anderen Dateien noch in einem anderen Aspekt. Eine winzige Änderung an einem einzigen Datensatz kann in vielen verschiedenen Änderungen an der eigentlichen Datenbankdatei resultieren. Zusätzlich zu dem direkt geänderten Datensatz, kann es einen oder mehrere Indizes geben, der aktualisiert werden muss, außerdem könnte die Speicherplatzallokation für die Tabelle und ihrer Datensätze erweitert werden müssen. – Einen einzelnen Buchstaben in einem Datensatz zu ändern, kann also Änderungen an vielen Stellen der Datei auslösen.

Transaktionen

Als wäre das noch nicht komplex genug, denk noch einen Schritt weiter. Wie die meisten Datenbanken verwendet Access Transaktionen um Datensätze in die Datenbank zu schreiben. Mehrere Änderungen an verschiedenen Datensätzen können in einer einzigen Transaktion zusammengefasst werden. Das heißt, all diese Änderungen müssen entweder komplett geschrieben werden, oder keine einzige davon darf gespeichert werden. Es gibt nichts dazwischen. Nachdem eine Transaktion abgeschlossen ist, ist es unmöglich nachzuvollziehen, welche Änderungen innerhalb einer gemeinsamen Transaktion vorgenommen wurden. Die Datenbank selbst braucht das nicht mehr zu wissen, sobald sie sichergestellt hat, dass die Transaktion erfolgreich abgeschlossen wurde. – Ein externer Synchronisierungsprozess, der zu einem späteren Zeitpunkt versucht diese Änderungen zu synchronisieren, müsste unbedingt wissen, welche Änderungen zu einer zusammenhängenden Transaktion gehört haben, um Änderungen an Daten bei einer Synchronisierung unterhalb der Dateiebene konsistent durchzuführen.

Replikation – Gibt’s nicht mehr

Access hatte mal eine Replikationsfunktionalität, die verschiedene, verteilte Kopien ein und derselben Datenbank ermöglicht hat. Diese Replikationsengine hat in einer speziell vorbereiteten Offline-Kopie der Access Datenbank alle Änderungen aufgezeichnet, um diese später auf eine Master-Kopie dieser Datenbank anzuwenden. Dieses Feature hat grundsätzlich funktioniert, aber es gab ein recht hohes Risiko von Synchronisationskonflikten und Benutzerfehlern, die unbeabsichtigter Weise zu Datenverlust führten. Die Replikationsfunktionalität wurde letztendlich von Microsoft in Access 2007 entfernt, als die Datenbankengine von JET zu ACE und das Dateiformat von .MDB zu .ACCDB geändert wurde.

Ich habe lange nach einem umfassenden Artikel über Access Replikation gesucht, um ihn hier zu verlinken, aber leider sind alle maßgeblichen Artikel zu Replikation von der Microsoft-Webseite entfernt worden.

Automatische Änderungen an der Datenbankdatei

Jetzt sollte es bereits klar sein, dass du nicht das gleiche Maß an Synchronisation von Access Datenbanken erwarten kannst. Das ist allerdings nur ein Teil des Problems. Es wird noch schlimmer.

Bei fast jedem anderen Dateityp wird nur in eine Datei geschrieben, wenn du tatsächlich etwas an den Daten geändert hast und explizit diese Änderungen speicherst. Ein rein lesender Zugriff auf eine Datei wird also niemals das letzte Dateiänderungsdatum verändern. Konflikte können nur bei schreibenden Zugriffen passieren, aber niemals zwischen einem schreibenden und einem lesenden Zugriff.

Das ist bei Access anders. Selbst wenn du eine Access Datenbank öffnest um nur lesen Daten anzuschauen und rein gar nichts an den Daten änderst, kann es passieren, dass Access in die .accdb- oder .mdb-Datei schreibt. Wenn du irgendeine Abfrage ausführst, und gilt bereits für einfache Select-Abfragen, könnte Access bereits interne, temporäre Daten, die erforderlich sind um die Abfrage auszuführen in die Datenbankdatei schreiben.

Wenn du neu geschriebenen, oder geänderten VBA-Code in deiner Anwendung hast, der gespeichert ist, aber noch nicht kompiliert wurde, dann muss dieser Code zwangsweise kompiliert werden, wenn seine Ausführung durch Benutzeraktionen in der Oberfläche ausgelöst wird. Der kompilierte Zustand des Codes wird dann automatisch gespeichert und ändert somit die Accessdatei, ohne dass du sie bewusst geändert hast.

Das resultierende Dilemma

Kombiniere jetzt die beiden, oben ausgeführten Fakten.

Erstens, das Access-Dateiformat ist sehr kompakt strukturiert und erlaubt es keiner externen Logik nachzuvollziehen, welche Änderungen zusammengefasst werden und als Ganzes auf eine andere Version der Datei angewendet werden müssen, um einen konsistenten Zustand herzustellen.

Zweitens, die Datei wird ständig sowohl mit beabsichtigen, wichtigen Änderungen als auch mit unwichtigen, internen, temporären Daten aktualisiert. Es ist unmöglich für eine Externe Logik diese zwei verschiedenen Typen von Änderungen auseinander zu halten.

Dies erzeugt ein Szenario, in dem es absolut unmöglich ist verschiedene, konkurrierende Version ein und derselben Datei verlässlich in einen konsistenten Zustand zu synchronisieren. Jeder Versuch, diese verschiedenen, konkurrierenden Änderungen zu verschmelzen, ist dazu verdammt fehlzuschlagen und wird höchstwahrscheinlich die Datenbank korrumpieren.

Wie du die Probleme umgehen kannst

Es kann funktionieren, eine Access Datenbank an einen geteilten, Offline-Speicherort abzulegen, wenn du absolut sichergehst, dass es niemals konkurrierende Änderungen an dieser Datei gibt. Das schließt ein, dass sicherstellst, dass alle Änderungen, die du an einer Offline-Kopie einer Datenbank vorgenommen hast, immer auf den zentralen Server synchronisiert werden, wenn du deine Arbeit abgeschlossen hast. Ganz genauso musst du aufpassen, dass der Synchronisierungsprozess immer die letzte Version in deinen lokalen OneDrive-/DropBox-Ordner abgerufen hat, bevor du die Datei öffnest und daran zu arbeiten beginnst. – Meiner Meinung nach, ist das in einem Mehrbenutzerszenario zu fehlerträchtig um es auch nur zu versuchen.

I speichere ein paar Demo- und Beispieldatenbanken in einen Windows Offline-Ordner. Ich bin die einzige Person, die an diesen Dateien arbeitet. Dies ist also wirklich das einzige Szenario in dem ich den Offline-Betrieb einer Access-Anwendung in Betracht ziehen würde. Ich versuche immer darauf zu achten, dass es keine konkurrierenden Änderungen an einer Datei gibt, so wie oben beschrieben. – Dennoch habe ich mit diesen Dateien die höchste Rate an Datenbankkorruption, die ich jemals mit Access erlebt habe.

Nur zum Vergleich, üblicherweise würde ich bei einer soliden Access Anwendung, die von bis zu 20 simultanen Benutzern in einem stabilen Netzwerk verwendet wird, höchstens ein oder zweimal im Jahr erwarten, dass es zu einer Datenbankkorruption kommt. Mit meinen eigenen, single-user Anwendungen in einem Offline-Ordner kommt es aber etwa einmal alle 30 Arbeitsstunden zu einer Datenbankkorruption.

Natürlich, die Ursache für die Korruption kann in den meisten Fällen auf einen Benutzerfehler zurückgeführt werden. Ich habe einfach vergessen, darauf zu achten, dass die Datenbank vollständig synchronisiert wurde, bevor ich die Datei auf einem anderen Rechner geöffnet habe. – Aber, es ist einfach sehr schwierig diese Art von Benutzerfehlern und die daraus resultierende Beschädigung der Datei zu vermeiden.

Fazit

Das Fazit führt uns wieder zu der eingangs gegebenen, einfachen Antwort. Teile deine Datenbank nicht mit anderen Benutzern auf OneDrive oder DropBox. Lege Datenbankdateien für einen eigenen Gebrauch nur dort ab, wenn du dir über die Risiken und die erforderliche Sorgfalt im Klaren bist. Selbst dann bleibt unter dem Strich der Rat: Tu das nur, wenn es unbedingt erforderlich ist.

Share this article: