Lektionen/Workflow

Datenbank aufteilen: Frontend & Backend

Fortgeschritten11 Min. Lesezeit

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:

  1. Öffne die Original-Datenbank.
  2. Datenbanktools → Access-Datenbank (Gruppe „Daten verschieben").
  3. 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 _be und ans Frontend _fe an. 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 RefreshLink einen 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 .accde ausliefern — 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 BackendNeuVerbinden auf, 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.Connect und stellst sie mit RefreshLink neu her, wenn das Backend umzieht.
  • Fürs Deployment gilt: Frontend lokal und am besten als .accde ausliefern, Backend beim Update stehen lassen.