Eine einzelne .accdb mit Tabellen, Formularen, Abfragen und Code ist bequem — bis
zwei Leute gleichzeitig damit arbeiten oder du ein Update ausliefern willst, ohne die
Daten zu überschreiben. Die Lösung ist ein Split: Daten und Oberfläche wandern in
zwei getrennte Dateien.
Warum aufteilen?
- Mehrbenutzerbetrieb — jeder Nutzer bekommt eine eigene Kopie des Frontends auf seinem Rechner. Alle greifen auf ein gemeinsames Backend im Netzwerk zu. Weniger Sperrkonflikte, stabilere Verbindungen.
- Einfache Updates — du verbesserst ein Formular und verteilst nur das neue Frontend. Die Daten im Backend bleiben unangetastet.
- Datensicherheit — das Backend enthält nur Tabellen und lässt sich gezielt sichern. Ein Absturz im Frontend gefährdet die Daten nicht.
┌─────────────────────┐
Nutzer A ───▶ │ Frontend_A.accdb │ ─┐
│ Formulare, Code, │ │ verknüpfte
│ verknüpfte Tabellen│ │ Tabellen
└─────────────────────┘ │
┌─────────────────────┐ ▼ ┌──────────────────┐
Nutzer B ───▶ │ Frontend_B.accdb │ ───▶ │ Backend.accdb │
└─────────────────────┘ │ nur Tabellen │
└──────────────────┘
Was ins Backend gehört
Ins Backend kommen ausschließlich die Tabellen (die echten Daten). Alles andere — Formulare, Berichte, Abfragen, Makros und VBA-Module — bleibt im Frontend. Das Frontend enthält statt eigener Tabellen verknüpfte Tabellen, die auf das Backend zeigen.
Der eingebaute Datenbank-Splitter
Access bringt einen Assistenten mit, der die Aufteilung automatisch erledigt:
- Öffne die Original-Datenbank.
- Datenbanktools → Access-Datenbank (Gruppe „Daten verschieben").
- Ziel für das Backend wählen (z. B.
S:\Daten\Firma_be.accdb).
Der Assistent verschiebt alle Tabellen ins Backend und ersetzt sie im Frontend durch Verknüpfungen. Die aktuelle Datei ist danach dein Frontend — kopiere sie für jeden Nutzer.
Namenskonvention: Häng ans Backend
_beund ans Frontend_fean. Das erspart später viel Verwirrung beim Deployment.
Verknüpfungen per VBA prüfen
Jede verknüpfte Tabelle ist ein TableDef, dessen Connect-Eigenschaft den Pfad
zum Backend enthält. Diese Prozedur listet alle Verknüpfungen auf:
Public Sub ZeigeVerknuepfungen()
Dim db As DAO.Database
Dim td As DAO.TableDef
Set db = CurrentDb
For Each td In db.TableDefs
' Nur verknüpfte Tabellen haben einen Connect-String
If Len(td.Connect) > 0 Then
Debug.Print td.Name & " → " & td.Connect
End If
Next td
End Sub
Der Connect-String sieht typisch so aus:
;DATABASE=S:\Daten\Firma_be.accdb
Verknüpfungen per VBA aktualisieren
Wenn das Backend umzieht (neuer Server, anderer Pfad), zeigen die Verknüpfungen ins
Leere. Statt jede Tabelle von Hand neu zu verknüpfen, setzt du den Connect-String
neu und rufst RefreshLink auf:
Public Sub BackendNeuVerbinden(ByVal neuerPfad As String)
Dim db As DAO.Database
Dim td As DAO.TableDef
Dim geaendert As Long
Set db = CurrentDb
For Each td In db.TableDefs
If Len(td.Connect) > 0 Then
td.Connect = ";DATABASE=" & neuerPfad
td.RefreshLink ' Verknüpfung neu herstellen
geaendert = geaendert + 1
End If
Next td
MsgBox geaendert & " Verknüpfung(en) auf " & neuerPfad & " gesetzt.", _
vbInformation
End Sub
Aufruf im Direktfenster (Strg+G):
BackendNeuVerbinden "S:\Daten\Firma_be.accdb"
Achtung: Existiert der Zielpfad nicht oder ist das Backend gesperrt, wirft
RefreshLinkeinen Laufzeitfehler. Fang ihn ab und melde die betroffene Tabelle:
On Error Resume Next
td.RefreshLink
If Err.Number <> 0 Then
Debug.Print "Fehler bei " & td.Name & ": " & Err.Description
Err.Clear
End If
On Error GoTo 0
Beim Start automatisch prüfen
Praktisch ist ein kleiner Test, der beim Start des Frontends prüft, ob das Backend
erreichbar ist — z. B. in einem Autostart-Makro oder der Form_Load-Prozedur eines
Startformulars:
Public Function BackendErreichbar() As Boolean
Dim db As DAO.Database
Dim td As DAO.TableDef
Set db = CurrentDb
For Each td In db.TableDefs
If Len(td.Connect) > 0 Then
' Pfad aus dem Connect-String hinter "DATABASE="
BackendErreichbar = (Len(Dir$(Mid$(td.Connect, _
InStr(td.Connect, "DATABASE=") + 9))) > 0)
Exit For
End If
Next td
End Function
Liefert die Funktion False, kannst du dem Nutzer eine verständliche Meldung zeigen,
statt ihn in kryptische Access-Fehler laufen zu lassen.
Deployment- und Update-Tipps
- Frontend lokal — leg das Frontend auf jeden Client, nicht auf das Netzlaufwerk. Ein gemeinsames Frontend im Netz führt zu Sperren und Datenbeschädigung.
- Als
.accdeausliefern — kompiliere das Frontend zu einer.accde. Der Code ist geschützt und lässt sich nicht versehentlich verändern. - Backend nur einmal — beim Update tauschst du nur die Frontend-Datei aus. Das Backend bleibt stehen, damit keine Daten verlorengehen.
- Verknüpfungen nach dem Kopieren prüfen — ruf nach dem Verteilen einmal
BackendNeuVerbindenauf, falls die Nutzer das Backend über unterschiedliche Pfade (Laufwerksbuchstaben) erreichen.
Zusammengefasst
- Ein Split trennt Daten (Backend, nur Tabellen) von der Oberfläche (Frontend, Formulare, Berichte, Code, verknüpfte Tabellen).
- Das bringt Mehrbenutzerbetrieb, einfache Updates und mehr Datensicherheit — jeder Nutzer bekommt eine eigene Frontend-Kopie.
- Der eingebaute Datenbank-Splitter erledigt die Aufteilung in wenigen Klicks.
- Per VBA prüfst du Verknüpfungen über
TableDef.Connectund stellst sie mitRefreshLinkneu her, wenn das Backend umzieht. - Fürs Deployment gilt: Frontend lokal und am besten als
.accdeausliefern, Backend beim Update stehen lassen.