Früher war ein Wackler gleich Datenverlust
Access über das Netzwerk zu nutzen war lange ein Glücksspiel.
Wenn das WLAN kurz zickt oder jemand den Laptopdeckel schließt – Datei beschädigt.
Fehler 3043, Datenbank wurde nicht richtig geschlossen.
Kennst Du sicher.
Heute sieht das besser aus.
Access ist robuster geworden – wenn Du es richtig aufziehst.
Was sich seit Office 365 getan hat
- Verbesserte Sperrmechanismen
- Mehr Fehlertoleranz bei Dateizugriffen
- Stabilere Trennung von Frontend und Backend
- Fehler 3043 wird seltener
- Temporäre Verbindungsabbrüche führen nicht mehr direkt zum Absturz
Aber: Das passiert nicht von allein. Du musst die Umgebung passend bauen.
Was Du dafür brauchst
- Getrenntes Backend auf Fileserver (keine OneDrive-Synchronisation!)
- Lokales Frontend pro Benutzer
- Stabile ODBC-Verbindung bei SQL Server
- Backup- und Kompaktstrategie
- Fehlerbehandlung bei allen kritischen Zugriffen
Beispiel: Frontend lokal starten
Viele starten Access direkt vom Netzlaufwerk.
Das ist wie Autofahren mit geöffnetem Tankdeckel.
Mach’s besser:
Public Sub StarteLokal()
Dim quelle As String
Dim ziel As String
quelle = "\\server\freigabe\AccessApp.accde"
ziel = Environ("USERPROFILE") & "\AppData\Local\AccessApp\AccessApp.accde"
If Dir(ziel) = "" Then
MkDir Environ("USERPROFILE") & "\AppData\Local\AccessApp"
FileCopy quelle, ziel
End If
Shell """" & ziel & """", vbNormalFocus
Application.Quit
End Sub
So läuft Access lokal – aber mit zentral verwalteter Version.
Beispiel: Prüfung auf Verbindung vor kritischem Zugriff
Public Function IstBackendErreichbar() As Boolean
On Error GoTo Fehler
Dim db As DAO.Database
Set db = DBEngine.OpenDatabase("\\server\freigabe\Backend.accdb")
db.Close
IstBackendErreichbar = True
Exit Function
Fehler:
IstBackendErreichbar = False
End Function
Vor jedem Datentransfer prüfen. Kein Zugriff? Dann abbrechen.
Beispiel: Abfragezugriffe mit Fehlerabsicherung
On Error GoTo Fehler
Dim rs As DAO.Recordset
Set rs = CurrentDb.OpenRecordset("SELECT * FROM Kunden WHERE Aktiv = True")
' ... Verarbeitung ...
rs.Close
Exit Sub
Fehler:
MsgBox "Netzwerkfehler oder Backend nicht erreichbar: " & Err.Description
So bleibt Dein Programm stabil – auch wenn das Netz mal kurz hängt.
Tabelle: Alt vs. Neu
Thema | Früher | Heute (richtig umgesetzt) |
---|---|---|
WLAN-Kurzunterbrechung | Datenbank beschädigt | Temporäre Abbrüche verkraftbar |
Datei auf Netzlaufwerk | Risiko hoch | Nur Backend auf Server |
Gemeinsame .accdb | Konflikte, Sperrprobleme | Lokale .accde pro Benutzer |
Fehlerbehandlung | selten vorhanden | gezielt eingebaut |
Performance bei Last | stark schwankend | stabil durch saubere Abfragen |
Mein Setup für robuste Netzwerkfähigkeit
Komponente | Umsetzung |
---|---|
Backend | .accdb auf stabilem Server |
Frontend | .accde lokal pro Nutzer |
Verbindung | UNC -Pfad, kein Netzlaufwerk-Buchstabe |
Recovery | Tägliche Sicherung + Komprimierung |
Fehlerprüfung | per VBA vor Datei- und Datenbankzugriffen |
Auf Dir ein WLAN-Kabel, oder
Access ist nicht unzuverlässig –
es wird nur oft schlecht behandelt.
Wenn Du’s richtig aufsetzt, läuft es auch im Netzwerk sauber.
Selbst bei schlechtem WLAN und hektischem Außendienst.
No responses yet