Wenn alles in einer Datei steckt, ist der Absturz nicht weit

Eine .accdb, 200 MB groß, auf dem Netzlaufwerk.
20 Benutzer greifen gleichzeitig zu.
Daten, Formulare, Abfragen, VBA – alles in einem.

Was kann schon schiefgehen?
Spoiler: Alles.

Warum die Trennung so wichtig ist

• Frontend (Formulare, VBA, Berichte) wird ständig geändert
• Backend (Tabellen, Daten) muss stabil bleiben
• Ein defektes Frontend betrifft nur den Benutzer
• Kein Sperren der Datenbankdatei
• Einfacheres Updaten: Neue Version einfach drüberkopieren
• Vorbereitung auf SQL-Backend möglich

Ohne Trennung:
Datenverlust, Performance-Probleme, ständiger Wartungsaufwand.

Was gehört wohin?

Bestandteil	Gehört ins Frontend	Gehört ins Backend
Tabellen		✅
Abfragen (Select)	✅
Formulare	✅
Berichte	✅
VBA-Module	✅
Makros	✅
Daten		✅

So stellst Du die Trennung her

Schritt 1: Ursprüngliche Datei sichern

Kopie machen. Immer.
Dann Backend-Datei erstellen.

Schritt 2: Tabellen in neue Datei exportieren

Access-Menü → Externe Daten → Access → In neue Datei exportieren.
Nur Tabellen. Ohne Beziehungen.

Tipp: Daten.accdb auf einem Netzlaufwerk speichern.

Schritt 3: Tabellen im Frontend verknüpfen

Im Frontend:
Externe Daten → Access → Link-Tabellen
Ziel: daten.accdb
Alle Tabellen markieren, verknüpfen.

Jetzt zeigt jede Tabelle im Frontend auf das Backend.
Im Tabellen-Icon ist ein kleiner Pfeil.

Tabellen verknüpfen per VBA

Damit’s auch automatisch geht – z. B. beim Start:

Public Sub TabellenNeuVerknuepfen()
    Dim tdf As DAO.TableDef
    Dim dbPfad As String
    dbPfad = "\\server\apps\daten.accdb"

    For Each tdf In CurrentDb.TableDefs
        If Len(tdf.Connect) > 0 Then
            tdf.Connect = ";DATABASE=" & dbPfad
            On Error Resume Next
            tdf.RefreshLink
            On Error GoTo 0
        End If
    Next
End Sub

Das ist hilfreich, wenn der Pfad sich ändert – z. B. bei neuen Servern.

Optional: SQL Server als Backend

Du kannst direkt auf SQL migrieren.
Access bleibt Frontend. Daten landen im SQL Server.

Tabellenimport z. B.:

SELECT * INTO KundenNeu
FROM OPENDATASOURCE('Microsoft.ACE.OLEDB.12.0',
  'Data Source=C:\pfad\daten.accdb')...Kunden;

Danach ODBC-Verknüpfung im Access-Frontend:

Dim tdf As TableDef
Set tdf = CurrentDb.CreateTableDef("dbo_Kunden")
tdf.Connect = "ODBC;DRIVER=ODBC Driver 17 for SQL Server;SERVER=sqlsrv01;DATABASE=meinDB;Trusted_Connection=Yes;"
tdf.SourceTableName = "dbo.Kunden"
CurrentDb.TableDefs.Append tdf

Wichtige Hinweise zur Trennung

• Keine Abfragen mit „Make-Table“ im Frontend laufen lassen
• Keine Temp-Tabellen im Backend speichern
• Nie VBA nutzen, um Backend-Tabellen zu löschen und neu zu erstellen
• Nutzer bekommen nur das Frontend (lokal), nie das Backend

Tabelle: Vergleich getrennter vs. ungetrennter Aufbau

Merkmal	Ohne Trennung	Mit Trennung
Updatefähigkeit	schlecht	sehr gut
Mehrbenutzerfähigkeit	instabil	stabil
Fehlertoleranz	niedrig	hoch (lokales Frontend)
Wartbarkeit	schwierig	strukturiert
Vorbereitung auf SQL	kaum möglich	direkt möglich

Mein Setup für saubere Trennung

Bereich	Vorgehen
Backend-Datei	daten.accdb zentral, Rechte: Lese/Schreiben
Frontend-Datei	lokal pro Nutzer, regelmäßig aktualisiert
Verknüpfung	automatisch per VBA
Deployment	Updater-Tool oder Loginskript
Entwicklung	getrennte Dev-/Live-Versionen

Access ist nicht schlecht. Aber es wird manchmal unnötig schlecht genutzt.

Wenn Du alles in eine Datei packst, arbeitest Du gegen die Architektur.

Trenn sauber – dann hält Deine Anwendung auch den nächsten Versionssprung aus.
Und zehn Nutzer gleichzeitig. Und Dich selbst in sechs Monaten.