Access im Netzwerk: Frontend und Backend trennen, bevor die Datei klemmt
Access ist kein Client-Server-System, sondern ein Dateisystem-Zugriff mit Datenbankfunktionen. Wer das weiß, versteht sofort, warum die Aufteilung keine Feinheit ist, sondern die Voraussetzung für alles andere.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die eine Datei auf dem Laufwerk funktioniert genau so lange, bis der zweite Mensch sie braucht
Fast jede Access-Anwendung im Haus fängt gleich an. Jemand baut sich für eine wiederkehrende Aufgabe eine Datenbank, legt Tabellen und ein Formular an, und weil das gut funktioniert, legt die Person die Datei auf ein gemeinsames Laufwerk, damit die Kollegin sie auch nutzen kann. Ab diesem Moment enthält eine einzige Datei zwei völlig verschiedene Dinge: den Datenbestand, der allen gehört, und die Oberfläche, die jeder einzeln benutzt. Solange nur eine Person die Datei geöffnet hat, fällt das nicht auf.
Auffällig wird es in drei Stufen. Zuerst kommen die Meldungen, dass die Datenbank von einem anderen Benutzer exklusiv gesperrt sei oder dass ein Objekt gerade nicht geändert werden könne. Dann wird es langsam, weil Access die Verarbeitung nicht auf dem Dateiserver erledigt, sondern auf jedem Arbeitsplatz einzeln, und die dafür nötigen Datenblöcke über das Netz holt. Und irgendwann kommt die Meldung, dass die Datei nicht in einem erwarteten Zustand ist und repariert werden muss. Bis dahin sind meist Monate vergangen, und niemand bringt den Zusammenhang mit der Bauweise in Verbindung.
Der eigentliche Schaden entsteht später. Weil die Oberfläche in derselben Datei steckt wie die Daten, kann niemand ein Formular ändern, ohne alle anderen herauszubitten. Weil jede Änderung an der Datei den gemeinsamen Datenbestand mitbewegt, ist jede Anpassung riskant. Und weil die Datei bei jedem Schreibvorgang wächst und erst beim Komprimieren wieder schrumpft, rückt die Grenze von zwei Gigabyte je Access-Datei näher, ohne dass jemand sie im Blick hat. Genau diese drei Punkte löst die Aufteilung auf einen Schlag.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Meldungen, die im Alltag wirklich auflaufen
Sortiert nach dem, was auf dem Bildschirm steht, und nicht nach der Systematik dahinter. Zu jedem Fall steht, was Access an dieser Stelle tatsächlich tut und welcher Eingriff ihn dauerhaft erledigt.
Symptom
Beim Öffnen meldet Access, die Datenbank sei von einem anderen Benutzer auf einem anderen Rechner exklusiv gesperrt, oder ein Objekt lasse sich gerade nicht in der Entwurfsansicht öffnen.
Ursache
Jemand hat die Datei exklusiv geöffnet, oder es wird versucht, die Struktur eines Objekts zu ändern, während andere darin arbeiten. Solange Oberfläche und Daten in einer Datei stecken, betrifft jede Entwurfsänderung zwangsläufig alle Verbundenen, denn sie ändert die gemeinsam genutzte Datei.
Lösung
Kurzfristig prüfst du in den Optionen, ob als Standardöffnungsmodus versehentlich der exklusive Zugriff eingestellt ist, und stellst auf freigegebenen Zugriff. Dauerhaft löst nur die Aufteilung das Problem: Wenn die Oberfläche lokal liegt, ändert jeder seine eigene Kopie, und niemand muss dafür herausgehen. Änderungen am Backend, also an Tabellen und Beziehungen, bleiben der seltene Fall, für den ein Wartungsfenster gerechtfertigt ist.
Symptom
Beim Speichern erscheint der Hinweis, dass ein anderer Benutzer den Datensatz geändert hat, und du kannst nur zwischen Verwerfen, Zwischenablage und Überschreiben wählen.
Ursache
Zwei Leute haben denselben Datensatz gleichzeitig geöffnet und geändert. In der Voreinstellung sperrt Access beim Bearbeiten nichts, prüft aber beim Speichern, ob sich der Datensatz zwischenzeitlich verändert hat. Das ist ein optimistisches Verfahren, das Konflikte nicht verhindert, sondern nur meldet.
Lösung
Stell in den Optionen die Standardsperrung auf den bearbeiteten Datensatz um, dann sperrt Access die Seite mit dem betroffenen Datensatz für die Dauer der Bearbeitung, und der zweite Zugriff bekommt sofort eine Rückmeldung statt später einen Konflikt. Aktivier zusätzlich die Sperrung auf Datensatzebene, sonst kann die Sperre benachbarte Datensätze mitnehmen. Wenn Konflikte dennoch häufig sind, ist das ein Hinweis darauf, dass zu viele Leute an derselben Stelle arbeiten, und dann hilft eher ein anderer Schnitt der Formulare.
Symptom
Die Datei wächst zwischen zwei Komprimierungen um ein Vielfaches, obwohl kaum neue Datensätze dazugekommen sind.
Ursache
Access gibt den Platz gelöschter oder geänderter Datensätze nicht sofort frei. Dazu kommen temporäre Objekte aus Abfragen und, wenn Oberfläche und Daten in einer Datei liegen, die Spuren jeder einzelnen Entwurfsänderung. Eine Datei, die ungeteilt im Team benutzt wird, wächst deshalb um ein Vielfaches schneller als eine reine Datentabellendatei.
Lösung
Trenn zuerst auf, damit die Oberfläche nicht mehr in die gemeinsame Datei schreibt. Setz danach für das Backend einen festen Komprimierungstermin außerhalb der Arbeitszeit, zu dem sicher niemand verbunden ist, und leg davor eine Kopie ab. Für das Frontend kannst du die Option zum Komprimieren beim Schließen einschalten, dort ist der Vorgang kurz und stört keinen anderen.
Symptom
Access meldet, die Datenbank befinde sich in einem unerwarteten Zustand und müsse repariert werden, oder ein Formular zeigt in einzelnen Feldern Zeichensalat.
Ursache
Fast immer ist eine Schreiboperation unterbrochen worden, etwa durch einen Netzaussetzer, einen abgestürzten Arbeitsplatz oder einen Rechner, der in den Ruhezustand gegangen ist, während die Datei offen war. Weil bei Access jeder Arbeitsplatz selbst in die Datei schreibt und kein Serverprozess dazwischensteht, wirkt so ein Abbruch unmittelbar auf die Datei.
Lösung
Spiel die letzte Sicherung ein und vergleich, was fehlt, statt sofort zu reparieren. Die eingebaute Reparatur ist der zweite Schritt, nicht der erste, denn sie kann beschädigte Datensätze auch entfernen. Damit der Fall seltener wird, gehören drei Dinge dazu: ein kabelgebundener oder zumindest stabiler Netzzugang für die betroffenen Arbeitsplätze, ausgeschalteter Ruhezustand während der Arbeitszeit und eine dauerhaft offen gehaltene Verbindung zum Backend.
Symptom
Nach dem Umzug des Backends auf einen neuen Server findet das Frontend die Tabellen nicht mehr, oder die Anwendung startet auf einem Rechner nicht, auf dem sie vorher lief.
Ursache
Die Verknüpfungen speichern den Pfad, unter dem das Backend beim Anlegen erreichbar war. Steht dort ein Laufwerksbuchstabe, hängt die Anwendung daran, dass genau dieser Buchstabe auf jedem Rechner auf dieselbe Freigabe zeigt. Nach einem Umzug oder einem neu aufgesetzten Arbeitsplatz ist das regelmäßig nicht mehr der Fall.
Lösung
Häng die Verknüpfungen mit dem Tabellenverknüpfungs-Manager auf den vollständigen Netzwerkpfad um, also auf Servername und Freigabe statt auf einen Buchstaben. Verteil danach ein frisches Frontend an alle Arbeitsplätze. Wenn ihr die Anwendung ohnehin über ein Startskript verteilt, ist das genau die Stelle, an der der neue Stand automatisch bei allen ankommt.
Symptom
Formulare und Berichte werden mit jedem zusätzlichen Menschen spürbar langsamer, obwohl der Datenbestand überschaubar ist.
Ursache
Access holt die Daten zur Verarbeitung an den Arbeitsplatz. Ein Formular, das eine ganze Tabelle als Datenquelle hat, oder ein Bericht, der ohne Einschränkung über alle Datensätze läuft, zieht deshalb weit mehr über das Netz, als der Bildschirm anschließend zeigt. Mit jeder zusätzlichen Verbindung summiert sich das.
Lösung
Gib jedem Formular und jedem Bericht eine Abfrage als Datenquelle, die die Menge bereits einschränkt, und setz Indizes auf die Felder, nach denen gefiltert und sortiert wird. Vermeide Formulare, die beim Öffnen sofort alle Datensätze laden, und arbeite stattdessen mit einer Auswahl vorweg. Wenn das ausgereizt ist und die Datenmenge weiter wächst, ist der Wechsel des Backends auf einen SQL Server der nächste Schritt, weil dann die Auswertung dort passiert und nur das Ergebnis über das Netz geht.
Fünf Fragen, und du weißt, ob eure Access-Anwendung netzwerkfähig ist
- 01 Liegen Tabellen und Oberfläche in derselben Datei oder in zwei getrennten Dateien?
- 02 Hat jeder Arbeitsplatz eine eigene lokale Kopie des Frontends oder öffnen alle dieselbe Datei?
- 03 Zeigen die Verknüpfungen auf einen UNC-Pfad oder auf einen Laufwerksbuchstaben?
- 04 Wie groß ist die Backend-Datei heute, und wie schnell wächst sie zwischen zwei Komprimierungen?
- 05 Wann wurde zuletzt eine Kopie des Backends gezogen, und wer hat das geprüft?
Was du nach dieser Seite an einem Vormittag umgestellt hast
Sechs Handgriffe, und keiner davon verlangt eine Zeile Code. Der erste ist der wichtigste, die übrigen fünf verhindern, dass du in den bekannten Fallen landest, die eine an sich richtige Aufteilung trotzdem unbrauchbar machen.
Tabellen und Oberfläche in zwei Dateien trennen
Das Backend enthält ausschließlich die Tabellen und liegt auf der Freigabe. Das Frontend enthält Formulare, Berichte, Abfragen, Makros und Module sowie Verknüpfungen auf die Tabellen im Backend. Access bringt dafür einen Assistenten mit, der die Tabellen in eine neue Datei verschiebt und die Verknüpfungen anlegt, aber du kannst den Schritt genauso gut von Hand machen: neue Datei anlegen, Tabellen importieren, im alten Bestand löschen, verknüpfen.
Jedem Arbeitsplatz eine eigene Frontend-Kopie geben
Ein Frontend, das auf der Freigabe liegt und von mehreren Leuten gleichzeitig geöffnet wird, hat dieselben Probleme wie vorher, nur ohne die Daten. Die Kopie gehört lokal auf den Rechner. Wer die Verteilung nicht von Hand machen will, legt ein kleines Startskript an, das die Datei bei jedem Aufruf frisch von einer Ablage kopiert und dann öffnet. Damit ist gleichzeitig geklärt, wie eine neue Version zu den Leuten kommt.
Die Verknüpfungen über den UNC-Pfad setzen, nicht über einen Laufwerksbuchstaben
Ein verbundenes Laufwerk heißt nicht auf jedem Rechner gleich und ist nach einem Neuaufbau des Arbeitsplatzes oft gar nicht mehr da. Der vollständige Netzwerkpfad in der Form mit zwei führenden Schrägstrichen, Servername und Freigabe funktioniert überall gleich. Wenn das Backend später umzieht, hängst du die Verknüpfungen mit dem Tabellenverknüpfungs-Manager um, statt sie einzeln neu anzulegen.
Eine Verbindung zum Backend dauerhaft offen halten
Access legt neben der Backend-Datei ein Lockfile an, solange jemand verbunden ist, und räumt es weg, wenn die letzte Verbindung endet. Wenn dieses Anlegen und Wegräumen ständig passiert, kostet das Zeit und erhöht das Risiko bei Netzaussetzern. Der übliche Gegengriff ist ein verstecktes Formular, das beim Start des Frontends eine kleine Tabelle aus dem Backend öffnet und bis zum Programmende offen lässt.
Die Sperrstrategie bewusst einstellen statt sie zu erben
Access sperrt auf Datensatzebene, nicht die ganze Datei, und genau darin liegt der Unterschied zu einer Tabelle in einer Tabellenkalkulation. In den Optionen legst du fest, ob beim Bearbeiten gar nicht, nur der bearbeitete Datensatz oder alle Datensätze gesperrt werden. Für den Alltag ist die Sperre auf den bearbeiteten Datensatz die Einstellung, die zu den wenigsten Überraschungen führt, weil Schreibkonflikte dann erst gar nicht entstehen.
Komprimieren und Sichern zu einem festen Termin machen
Eine Access-Datei wächst bei jeder Änderung und gibt den Platz erst beim Komprimieren wieder frei. Für das Backend heißt das: ein fester Termin außerhalb der Arbeitszeit, an dem niemand verbunden ist, und davor eine Kopie der Datei. Das Frontend kann bei jedem Schließen komprimieren, dort stört es nicht. Die Sicherung des Backends ist dabei der wichtigere Teil, denn eine beschädigte Access-Datei lässt sich reparieren, aber nicht immer vollständig.
Die Grenze im Blick behalten und den Ausstieg vorbereiten
Microsoft nennt für den Umstieg auf einen SQL Server zwei Anhaltspunkte: die Größe der Datenbank und die Zahl gleichzeitiger Zugriffe. Eine Access-Datei fasst zwei Gigabyte, und laut Microsoft werden bis zu 255 gleichzeitige Nutzer unterstützt. Aus der Praxis kommt ein dritter Wert dazu: Flüssig läuft eine geteilte Lösung meist nur bis zu etwa einem Gigabyte Daten und einer niedrigen zweistelligen Zahl gleichzeitiger Verbindungen. Wenn ihr euch einem dieser Werte nähert, ist die Trennung von Frontend und Backend genau der Zustand, aus dem der Wechsel des Backends auf einen SQL Server ohne Neubau der Oberfläche möglich ist.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Warum Access im Netzwerk anders funktioniert, als die meisten annehmen
Bei einem klassischen Datenbankserver schickt der Arbeitsplatz eine Anfrage, der Server sucht die Antwort heraus und schickt das Ergebnis zurück. Bei einer Access-Datei auf einer Freigabe passiert etwas anderes: Der Dateiserver stellt nur die Datei bereit, und die eigentliche Arbeit erledigt die Datenbank-Engine auf dem Arbeitsplatz. Alles, was für eine Abfrage gebraucht wird, wandert dafür über das Netz an den Rechner, der sie gestellt hat. Das ist kein Mangel, sondern die Bauweise, und sie erklärt fast jedes Verhalten, über das im Alltag gestolpert wird.
Aus dieser Bauweise folgt unmittelbar, warum eine gemeinsame Datei so empfindlich ist. Jeder verbundene Arbeitsplatz schreibt selbst in dieselbe Datei. Es gibt keinen Prozess dazwischen, der eine abgebrochene Schreiboperation zu Ende führen oder zurücknehmen könnte. Bricht die Verbindung mitten im Schreiben ab, bleibt die Datei in einem Zustand zurück, den Access beim nächsten Öffnen als beschädigt erkennt. Deshalb ist die Frage nach der Stabilität des Netzes bei Access keine Nebensache, sondern Teil der Anwendungsarchitektur.
Damit sich die Arbeitsplätze untereinander abstimmen, legt Access neben der Datenbankdatei ein Lockfile mit demselben Namen an, im aktuellen Format mit der Endung laccdb, im älteren mit der Endung ldb. Darin steht, wer gerade verbunden ist. Diese Datei entsteht, sobald die erste Verbindung aufgebaut wird, und verschwindet, wenn die letzte endet. Wenn sie nach Feierabend noch da ist, hängt entweder noch eine Sitzung, oder eine Sitzung ist nicht sauber beendet worden. Für einen Komprimierungslauf ist genau das die Prüfung, die davor gehört.
Was ins Backend gehört und was ins Frontend
Die Trennlinie verläuft nicht zwischen wichtig und unwichtig, sondern zwischen gemeinsam und individuell. Gemeinsam ist der Datenbestand, also die Tabellen mit ihren Feldern, Indizes und Beziehungen. Individuell ist alles, was jemand benutzt, um an diesen Bestand heranzukommen: Formulare, Berichte, Abfragen, Makros, Module und die Anwendungsoptionen. Alles Gemeinsame gehört ins Backend auf der Freigabe, alles Individuelle ins Frontend auf dem Arbeitsplatz.
Zwei Fälle sitzen erfahrungsgemäß zwischen den Stühlen. Der erste sind Hilfstabellen, in die die Anwendung während der Arbeit schreibt, etwa Zwischenergebnisse für einen Bericht oder eine Merkliste. Die gehören ins Frontend, denn sonst schreiben mehrere Leute gleichzeitig in dieselben Zeilen und stören sich gegenseitig. Der zweite Fall sind Nachschlagelisten mit Werten wie Abteilungen oder Statusbezeichnungen. Die gehören ins Backend, weil sie für alle gleich sein müssen, auch wenn sie sich selten ändern.
Für die Verteilung des Frontends gibt es zwei gängige Wege. Der einfache ist ein Startskript, das die aktuelle Fassung von einer Ablage in ein lokales Verzeichnis kopiert und dann öffnet. Damit hat jeder immer den aktuellen Stand, und du brauchst dich nicht darum zu kümmern, wer welche Version hat. Der aufwendigere Weg legt zusätzlich eine kompilierte Fassung als accde ab, in der die Entwurfsansichten und der Quelltext der Module nicht mehr zugänglich sind. Das ist kein Schutz gegen jemanden, der wirklich hineinwill, aber es verhindert zuverlässig die versehentliche Änderung an einem Formular.
Sperren, Konflikte und die Einstellungen, die darüber entscheiden
Access sperrt auf der Ebene einzelner Datensätze, und das ist der Punkt, an dem es sich von einer geteilten Tabellenkalkulation grundlegend unterscheidet: Dort ist die Datei als Ganzes betroffen, hier nur die Zeile, an der gerade jemand arbeitet. Wie streng das gehandhabt wird, entscheidet eine Einstellung in den Optionen, und die wird selten bewusst gesetzt. Zur Wahl stehen keine Sperrung, die Sperrung des bearbeiteten Datensatzes und die Sperrung aller Datensätze in der Datenquelle.
Ohne Sperrung arbeitet Access optimistisch: Zwei Leute dürfen denselben Datensatz öffnen und ändern, und erst beim Speichern des zweiten stellt Access fest, dass sich zwischenzeitlich etwas verändert hat. Es kommt dann die bekannte Rückfrage, ob die eigene Fassung die andere überschreiben soll. Diese Rückfrage ist der Moment, in dem im Alltag Arbeit verloren geht, denn sie kommt unter Zeitdruck und bietet als bequemste Antwort das Überschreiben an.
Mit der Sperrung des bearbeiteten Datensatzes arbeitet Access pessimistisch: Wer zuerst anfängt zu tippen, hält den Datensatz, und der zweite Zugriff bekommt sofort den Hinweis, dass gerade jemand anderes daran ist. Das ist im Moment unbequemer, verhindert aber genau den Fall, in dem still etwas überschrieben wird. Wichtig ist dabei die zweite Einstellung dazu: Ist die Sperrung auf Datensatzebene nicht aktiviert, sperrt Access den ganzen Block, in dem der Datensatz liegt, und damit unter Umständen auch Nachbarn, die niemand angefasst hat. Wer pessimistisch sperrt, schaltet beides zusammen ein.
Wann die Aufteilung nicht mehr reicht
Die Aufteilung löst die Blockaden und macht die Anwendung wartbar, aber sie ändert nichts daran, dass die Verarbeitung weiterhin am Arbeitsplatz stattfindet und die Daten dafür über das Netz wandern. Deshalb gibt es einen Punkt, an dem auch eine sauber getrennte Access-Lösung an ihre Grenze kommt. Microsoft nennt in der Anleitung zur Migration auf einen SQL Server zwei Anhaltspunkte: eine Größenbeschränkung von zwei Gigabyte je Access-Datenbank und die Aussage, dass Access nicht mehr als 255 gleichzeitige Benutzer unterstützt. Aus der Praxis kommt ein dritter Wert dazu, den Microsoft dort nicht nennt: Flüssig läuft eine geteilte Access-Lösung meist nur bis zu einem Datenbestand von etwa einem Gigabyte und einer niedrigen zweistelligen Zahl gleichzeitiger Verbindungen.
Neben diesen Zahlen gibt es weichere Anzeichen, die genauso ernst zu nehmen sind. Wenn Auswertungen so lange laufen, dass die Leute sie über Mittag anstoßen. Wenn die Anwendung Daten enthält, deren Verlust nicht nur ärgerlich, sondern meldepflichtig wäre. Wenn mehrere Standorte über eine Weitverkehrsverbindung darauf zugreifen sollen. Und wenn außer Access noch andere Programme an dieselben Daten müssen. In all diesen Fällen ist nicht die Oberfläche das Problem, sondern der Ort, an dem gerechnet wird.
Der Ausweg ist deshalb kein Neubau, sondern ein Austausch der unteren Hälfte. Die Tabellen wandern auf einen SQL Server, im Frontend bleiben Formulare und Berichte, und die Verknüpfungen zeigen statt auf eine Datei auf den Server. Genau dafür ist die Trennung von Frontend und Backend die Voraussetzung: In einer ungeteilten Datei müsstest du die Anwendung erst auseinandernehmen, bevor du überhaupt anfangen könntest. Wer heute trennt, hält sich diesen Weg offen, auch wenn er in absehbarer Zeit nicht gebraucht wird.
Dazu passende Kurse
Weil sich die Aufteilung an der eigenen Datenbank in zwei Stunden erklären lässt, aber aus der Dokumentation heraus einen Tag kostet, sind Access-Kurse zum Mehrbenutzerbetrieb im Netzwerk der kürzere Weg.
Wenn dieselbe Frage bei euch auch für Listen in anderen Programmen auftaucht, findest du bei cmt Office-Seminare rund um gemeinsam genutzte Datenbestände .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Sehr kompetenter Dozent mit einem intensiven Training welches anwendungsorientiert ist.
Das doch recht "langweilige" Thema Excel, wurde einem sehr gut präsentiert. Durch direktes mitarbeiten wurde es einem nie langweilig.
Vielen Dank für die sehr informative und unterhaltsame Schulung!
Häufige Fragen
Reicht es nicht, die Datei einfach auf einem schnelleren Server abzulegen?
Was ist die Datei mit der Endung laccdb neben unserer Datenbank?
Wie bekommen alle eine neue Version des Frontends, ohne dass ich an jeden Platz gehe?
Muss ich den Assistenten zum Aufteilen benutzen?
Können wir eine aufgeteilte Access-Anwendung auch über eine Weitverkehrsverbindung nutzen?
Ab wann sollten wir das Backend auf einen SQL Server umstellen?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Office-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die eigene Datenbank einmal auseinandernehmen
Im Access-Aufbaukurs bei cmt gehst du die Aufteilung an einer echten Datenbank durch, von den verknüpften Tabellen über die Sperreinstellungen bis zur Verteilung des Frontends. Wer schon weiß, dass der SQL Server der nächste Schritt ist, findet die Fortsetzung im Kurs zum Zusammenspiel von Access und SQL Server.
Passt dazu
- Access oder Excel für eine kleine Datenbank: die Grenze liegt bei den Beziehungen
- Tabellen in Access verknüpfen: Beziehungen, die spätere Abfragen retten
- Access-Daten nach Excel, Word und Outlook bringen
- Access ist in eurer Lizenz nicht dabei: welche Wege dann bleiben