Warum deine Access-Datenbank langsamer wird, je mehr Leute damit arbeiten

Von /

Eine Person legt die Datenbank an, alles läuft. Zwei Jahre später sollen fünf Leute gleichzeitig damit arbeiten, und plötzlich hängt die Maske, der Bericht braucht eine Minute, und ab und zu kommt die Meldung, dass ein anderer Benutzer den Datensatz gerade geändert hat. Der erste Verdacht: Access ist am Ende. Der Verdacht ist fast immer falsch.

Nicht Access ist das Problem. Das Problem ist, wo die Daten liegen. Eine .mdb– oder .accdb-Datei auf einem Netzlaufwerk ist kein Datenbankserver, sie ist eine Datei. Und eine Datei wird nicht schneller, wenn mehr Leute gleichzeitig hineingreifen.

Eine Datei ist kein Server

Access bringt zwei Dinge in einem Paket mit: die Masken, Berichte und Abläufe, die deine Leute kennen, und eine Datei-Datenbank (die Jet- bzw. ACE-Engine), in der die Daten stehen. Solange beides in einer Datei auf einem Netzlaufwerk liegt, gilt eine harte Regel: Jeder Arbeitsplatz öffnet dieselbe Datei über das Netzwerk und holt sich die Daten satzweise selbst.

Bei einem Nutzer fällt das nicht auf. Bei fünf schon. Sucht jemand einen Datensatz, wandert nicht „die fertige Antwort“ durch das Netz, sondern oft die halbe Tabelle. Sperren werden über eine Begleitdatei (.ldb bei .mdb, .laccdb bei .accdb) verwaltet, die alle gleichzeitig lesen und schreiben. Genau hier entstehen die Hänger, die Schreibkonflikte und im schlimmsten Fall die beschädigte Datei nach einem Netzaussetzer.

In einem Fall aus meiner Praxis war es noch deutlicher: Die Datenbank lag nicht einmal getrennt in Frontend und Backend vor. Alles steckte in einer einzigen .mdb. Faktisch konnte immer nur ein Mensch sinnvoll damit arbeiten, alle anderen warteten oder riskierten Konflikte. Das ist kein Access-Defekt. Das ist Architektur.

Die eigentliche Lösung: Backend tauschen, Frontend behalten

Der Hebel ist eine Trennung, die viele schon halb kennen: Frontend (die Access-Datei mit Masken und Berichten auf jedem Arbeitsplatz) und Backend (die Daten). Beim Backend ersetzt du die Datei durch einen echten Datenbankserver, den SQL Server. Die Masken bleiben, wie sie sind.

Ein Datenbankserver beantwortet Abfragen dort, wo die Daten liegen, und schickt nur das Ergebnis zurück. Mehrbenutzer-Betrieb, Sperren auf Satzebene, Indizes, die wirklich greifen: Das ist seine Kernaufgabe, nicht ein Nebeneffekt. Der Unterschied zwischen „Datei über Netz“ und „Server“ ist genau der Unterschied zwischen „jeder blättert selbst durch den Aktenschrank“ und „du fragst, jemand bringt dir das eine Blatt“.

Der Weg dahin in drei Schritten:

  1. Frontend und Backend trennen, falls noch nicht geschehen. Die Daten kommen in eine eigene Backend-Datei, die Masken bleiben im Frontend.
  2. Daten auf den SQL Server heben. Microsofts kostenloser SQL Server Migration Assistant (SSMA) für Access übernimmt Tabellen, Daten und einfache Abfragen. Wichtig: SSMA fasst Formulare, Berichte und VBA nicht an. Genau deshalb funktioniert „Frontend bleibt“: Das Migrations-Werkzeug rührt deine Masken gar nicht an.
  3. Frontend neu verknüpfen über eine ODBC-Verbindung. Die Access-Tabellen werden zu verknüpften Tabellen, die in Wahrheit auf dem SQL Server liegen. Für den Anwender ändert sich an der Oberfläche nichts.

Ein Detail entscheidet darüber, ob die nervigen „ein anderer Benutzer hat den Datensatz geändert“-Meldungen verschwinden: eine ROWVERSION-Spalte je Tabelle. Access nutzt sie über ODBC, um Änderungen sauber zu erkennen, statt alle Felder zu vergleichen. Der folgende Ausschnitt zeigt das an einer anonymisierten Tabelle:

CREATE TABLE dbo.tblVeranstaltung
(
     idVeranstaltung        INT IDENTITY(1,1) NOT NULL
    ,intVstJahr      SMALLINT          NOT NULL
    ,strVstName      NVARCHAR(120)     NOT NULL
    ,dtmVstAngelegt  DATETIME2(0)      NOT NULL
        CONSTRAINT DF_Veranstaltung_Angelegt DEFAULT (SYSDATETIME())
    ,rvVst           ROWVERSION        NOT NULL
    ,CONSTRAINT PK_Veranstaltung PRIMARY KEY CLUSTERED (idVeranstaltung)
    ,CONSTRAINT UQ_Veranstaltung_Jahr_Name UNIQUE (intVstJahr, strVstName)
);

Die rvVst-Spalte ist der stille Held: Mit ihr hört Access auf, beim Speichern in Panik zu geraten, sobald zwei Leute fast gleichzeitig denselben Satz anfassen. Die UNIQUE-Bedingung über Jahr und Name ist hier kein Schmuck, sondern die direkte Antwort auf den eigentlichen Fehler dieses Projekts, dazu gleich mehr.

Der größere Hebel war nicht die Geschwindigkeit, sondern das Datenmodell

Beim genannten Verband war die Lahmheit nur das Symptom, das auffiel. Darunter lag ein klassischer Anfängerfehler: Die Veranstaltungen wurden jedes Jahr überschrieben, statt für jedes Jahr neue Datensätze anzulegen. Es gab also keine Historie, nur einen Zustand „jetzt“. Dazu weitere unsaubere Stellen im Modell, die jede Auswertung in Handarbeit verwandelten.

Hier zeigt sich, warum „nur schnell den Backend tauschen“ zu kurz greift. Ein reiner Umzug auf den SQL Server hätte die Abstürze beseitigt und die manuelle Arbeit behalten. Erst das saubere, normalisierte Datenmodell macht den Unterschied: Mit einer echten Jahres-Historie lassen sich Prozesse, die vorher von Hand liefen, vollständig automatisieren. Im Ergebnis sparte die Geschäftsstelle mehrere Stunden Sachbearbeitung pro Woche, nicht durch ein neues Programm, sondern durch ein Modell, das die Realität endlich richtig abbildet.

Das ist der Kern meiner Arbeitsweise: Struktur vor Tool. Ein neuer Datenbankserver auf einem kaputten Datenmodell ist nur ein schnellerer Weg zu denselben Problemen.

Logik wandert dahin, wo sie hingehört: auf den Server

Sobald die Daten auf dem SQL Server liegen, kannst du Logik dorthin verlagern, wo sie ohne Wartezeit für den Anwender läuft. Drei Bausteine:

  • Trigger und Regeln prüfen und ergänzen Daten direkt beim Speichern. Eine doppelte Mitgliedsnummer kommt gar nicht erst durch.
  • Indexoptimierte Abfragen liefern Auswertungen in Sekunden statt Minuten, weil der Server gezielt sucht, statt eine Tabelle komplett durch das Netz zu ziehen.
  • Nächtliche Prozeduren erledigen schwere Aufgaben dann, wenn niemand wartet: Beitragsläufe vorbereiten, Daten verdichten, Listen erzeugen.

Ein ehrlicher Stolperstein an dieser Stelle: Der nächtliche Teil läuft auf der kostenlosen Express-Edition nicht über den SQL Server Agent, denn den hat Express nicht. Stattdessen ruft die Windows-Aufgabenplanung per sqlcmd die Prozedur zur gewünschten Uhrzeit auf. Funktioniert zuverlässig, man muss es nur wissen. Trigger und Prozeduren selbst laufen auf Express ganz normal.

„Wir haben gar keinen SQL Server“ ist selten ein echtes Hindernis

Die meisten Firmen mit 30 bis 300 Mitarbeitenden haben längst einen SQL Server im Haus, oft als Backend ihrer Warenwirtschaft oder Branchensoftware. Wo keiner da ist, reicht die kostenlose Express-Edition für erstaunlich viel.

Mit SQL Server 2025 hat Microsoft die Grenze der Express-Edition von 10 GB auf 50 GB je Datenbank angehoben. Für eine Mitgliederverwaltung, eine Auftragsverwaltung oder ein Spezial-Frontend ist das reichlich Luft. Genau das war im beschriebenen Projekt der Fall: kein SQL Server vorhanden, Express 2025 eingerichtet, fertig. Keine Lizenzkosten.

Die Grenzen der Express-Edition gehören trotzdem auf den Tisch: ein CPU-Sockel und höchstens vier Kerne, rund 1,4 GB Arbeitsspeicher für den Datencache, kein SQL Server Agent, keine eingebaute Hochverfügbarkeit. Für die meisten Spontan-Frontends und Abteilungslösungen ist das kein Problem. Wer hohe gleichzeitige Schreiblast, mehr als 50 GB oder echte Ausfallsicherheit braucht, landet bei der Standard-Edition. Diese Entscheidung trifft man bewusst, nicht aus Versehen.

Wo der Ansatz an Grenzen stößt

Ein Backend-Tausch ist kein Allheilmittel. Drei ehrliche Einschränkungen:

Erstens hilft er nichts gegen ein kaputtes Datenmodell. Wenn überschrieben statt historisiert wird, bleibt der Schmerz, nur schneller. Zweitens muss das Frontend mitspielen: Abfragen, die stur ganze Tabellen ziehen, bleiben langsam, bis sie serverseitig als Sichten oder Prozeduren neu gedacht sind. Drittens ist die Express-Edition eine bewusste Wahl mit Grenzen, kein „kostenlos ist immer genug“.

Und ja, irgendwann kann ein gewachsenes Access-Frontend selbst zur Last werden. Dann ist die Frage, ob man Teile per Power Platform ergänzt. Wie sich ein SQL-Server-Backend sauber mit der Power Platform kombinieren lässt, habe ich an anderer Stelle beschrieben. Der erste Schritt bleibt aber fast immer derselbe: erst das Backend ordnen.

Was das für dich als Entscheider bedeutet

Übersetzt aus der Technik: Du musst kein neues Programm kaufen, niemand muss umlernen, die gewohnten Masken bleiben. Was verschwindet, sind die Abstürze, die Wartezeiten und das „nur einer kann gleichzeitig arbeiten“. Was dazukommt, ist Tempo bei Auswertungen und die Möglichkeit, Handarbeit zu automatisieren.

Eine Access-Anwendung, die langsam wird, je mehr Leute damit arbeiten, ist kein Fall für die Mülltonne. Sie ist ein Fall für ein anderes Backend. Häufig zum Preis von null Lizenzkosten und ohne den Bruch, den ein kompletter Systemwechsel mit sich bringt.

Wer seine eigene Access-Anwendung einmal daraufhin anschauen lassen möchte, erreicht mich über das kostenlose Erstgespräch.

Quellen

Über den Autor

Sönke Schäfer ist selbstständiger IT-Berater und Datenarchitekt aus Sierksdorf in Ostholstein. Er begleitet norddeutsche KMU seit über 25 Jahren bei der Modernisierung von Microsoft-Access-Anwendungen, mit Schwerpunkt auf Migrationen nach SQL Server und der pragmatischen Weiterentwicklung gewachsener Datenbestände, ohne teuren Systemwechsel. Mehr unter Datenschäfer, Sönke Schäfer.

Ähnliche Beiträge

Nach oben scrollen