Warum das nicht einfach geht

Access ist keine Server-Datenbank.
Wenn mehrere gleichzeitig drauf zugreifen, kracht’s gern.
Aber: Mit sauberer Trennung geht’s erstaunlich stabil.

Backend und Frontend trennen

Deine .accdb-Datei enthält oft alles: Tabellen, Formulare, Abfragen, Code.
Für den Mehrbenutzerbetrieb musst Du das aufteilen.

So mach ich’s:

1. Datenbank aufteilen mit dem Access-Assistenten (Frontend/Backend)
2. Backend (mit Tabellen) auf Netzlaufwerk legen
3. Frontend (mit Formularen und Code) lokal bei jedem Nutzer

Netzlaufwerk: Stabilität zählt

Backend kommt nicht auf ein wild gemapptes Netzlaufwerk wie Z:\.
Ich arbeite nur mit UNC-Pfaden wie:

\\SERVER01\AccessDB\backend.accdb

Gemapptes Laufwerk + anderer Laufwerksbuchstabe = Probleme.

Tabellenverknüpfung automatisch prüfen

Ich baue mir beim Start einen Verbindungs-Check ein.

VBA: Tabellenverknüpfung prüfen und ggf. neu verbinden

Sub TabellenNeuVerknüpfen()
  Dim tdf As TableDef
  Dim db As Database
  Set db = CurrentDb

  For Each tdf In db.TableDefs
    If Len(tdf.Connect) > 0 Then
      On Error Resume Next
      tdf.RefreshLink
      If Err.Number <> 0 Then
        MsgBox "Verbindung zu " & tdf.Name & " ist fehlerhaft.", vbExclamation
        Exit Sub
      End If
    End If
  Next
End Sub

Das läuft beim Start und fängt ab, wenn das Backend fehlt oder verschoben wurde.

Schreibkonflikte vermeiden

Access sperrt Datensätze beim Schreiben.
Gleichzeitig speichern = Sperrfehler.
Ich verhindere das so:

• Formulare nur mit Einzel-Datensatz laden
• Kein automatisches Speichern bei Navigation
• Manuelles Speichern per Button

VBA: Speichern erzwingen

If Me.Dirty Then Me.Dirty = False

Temporäre Tabellen sind tabu

Wenn mehrere Nutzer gleichzeitig dieselbe Tabelle befüllen, knallt’s.
Lösungen:

• Jede*r bekommt eine eigene Temp-Tabelle (z. B. mit Benutzerkennung im Namen)
• Oder: Temporäre Daten nur lokal im Frontend halten

Protokollierung sinnvoll machen

Bei mehreren Usern will man wissen, wer was geändert hat.
Ich nutze oft Trigger in SQL Server – aber auch in Access geht was.

VBA: Änderungsprotokoll schreiben

Private Sub Form_BeforeUpdate(Cancel As Integer)
  Dim sSQL As String
  sSQL = "INSERT INTO LogTabelle (Tabelle, Benutzer, Zeitstempel) VALUES " & _
         "('Kunden', '" & Environ("USERNAME") & "', Now())"
  CurrentDb.Execute sSQL, dbFailOnError
End Sub

Nicht schön, aber zweckmäßig.

Performance? Wird schnell zum Problem

Je mehr Nutzer gleichzeitig auf das Backend zugreifen, desto langsamer wird’s.
Ich achte auf:

• Wenig Abfragen über verknüpfte Tabellen
• Kein Daueroffenhalten großer Recordsets
• Alle Formulare mit Filter starten

SQL Server als Backend? Ja bitte.

Wenn’s ernst wird, ziehe ich die Tabellen auf den SQL Server um.
Access bleibt Frontend, die Performance steigt spürbar.

T-SQL: Beispiel für Anbindung via ODBC

SELECT * FROM Kunden WHERE Aktiv = 1

In Access dann über ODBC verknüpft – z. B. mit DSN oder DSN-less.

DSN-less ODBC-Verbindung (VBA)

Sub DSNlessVerknüpfen()
  Dim db As DAO.Database
  Set db = CurrentDb
  db.Execute "DROP TABLE Kunden", dbFailOnError
  db.Execute "CREATE TABLE Kunden IN '' [ODBC;Driver={SQL Server};Server=SERVER01;Database=DB;Trusted_Connection=Yes;] Kunden", dbFailOnError
End Sub

Geht schnell, läuft stabiler als Jet-Netzwerkbetrieb.

Sperren überwachen

Wenn jemand abstürzt, bleiben *.laccdb-Dateien übrig.
Die verhindern Neustart.

Ich prüfe bei jedem Start:

• Gibt es eine bestehende Sperrdatei?
• Wurde sie vor über x Minuten erstellt?
• Dann: Hinweis geben oder löschen

Mein Grundsatz

Frontend lokal, Backend stabil, Zugriff sparsam.
Dann läuft Access auch mit 10 Leuten nebeneinander.