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.
No responses yet