Wenn .mdb noch läuft, aber keiner mehr weiß wie

Du kennst das:
In irgendeinem Netzlaufwerk liegt eine Datei namens kunden.mdb.
Letzte Änderung: 2012.
Wird „noch gebraucht“. Läuft „schon ewig“.

Und genau da liegt das Problem.

Was ist das Problem mit MDB?

• Format ist veraltet (seit Access 2007 nicht mehr Standard)
• Keine Verschlüsselung auf aktuellem Niveau
• Keine Mehrbenutzer-Performance
• Keine Unterstützung für lange Dateinamen oder Mehrwertdatentypen
• Keine laufende Sicherheitsentwicklung mehr

Die Datei öffnet sich noch.
Aber nicht mehr zuverlässig.
Und oft nicht mehr sicher.

Kompatibilitätsprobleme mit moderner Office-Version

Access 64-Bit mag MDB nur eingeschränkt.
Viele alte API-Aufrufe knallen.
Verweise auf DAO oder ADO fehlen oder zeigen ins Leere.
Und sobald ein Kollege mit Access 365 speichert, geht’s bei anderen kaputt.

Beispiel für fehlenden Verweis in VBA:

Dim db As DAO.Database
Set db = CurrentDb

Fehler 91: Objektvariable nicht festgelegt
Weil DAO nicht richtig geladen wird.

Sicherheitsprobleme: Passwortschutz ist nutzlos

Ein MDB-Passwort kann mit einem simplen Tool entfernt werden.
Der Algorithmus ist öffentlich dokumentiert.
Zugriffsschutz ist also rein kosmetisch.

Ein Beispiel per T-SQL (wenn MDB via ODBC erreichbar):

SELECT * FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0',
  'Jet OLEDB:Database Password=xyz;Data Source=\\netz\alt\kunden.mdb;',
  'SELECT * FROM Kunden');

Funktioniert – auch ohne Access.
Und ohne Einschränkungen.

Keine ACLs, keine Protokollierung, kein Schutz

Eine MDB kennt keine Benutzerkonten.
Jeder, der sie öffnen kann, darf alles.
Und: Es gibt kein Änderungsprotokoll.
Du weißt nie, wer was wann gemacht hat.

Schlechte Mehrbenutzerfähigkeit

Ja, theoretisch können mehrere User auf eine MDB zugreifen.
Aber praktisch bekommst Du:

• Sperrprobleme
• Datenverlust bei Parallelzugriff
• Datei-Locks, die nicht mehr verschwinden
• Fehler 3048: „Maximale Anzahl an Datenbankobjekten erreicht“

Migration auf ACCDB oder SQL Server

Schritt 1: Format konvertieren

Application.ConvertAccessProject "C:\daten\alt.mdb", "C:\daten\neu.accdb", acFileFormatAccess2007

Oder manuell: Öffnen mit aktuellem Access → Speichern unter ACCDB.

Schritt 2: Prüfung auf veraltete Objekte

• Makros durch VBA ersetzen
• Benutzerdefinierte Menüleisten löschen
• Berichte modernisieren
• Referenzen aktualisieren

Schritt 3: SQL-Backend nutzen

Die beste Variante: SQL Server im Backend, ACCDB im Frontend.

Dim tdf As DAO.TableDef
Set tdf = CurrentDb.CreateTableDef("tblKunden")
tdf.Connect = "ODBC;DRIVER=ODBC Driver 17 for SQL Server;SERVER=meinserver;DATABASE=meinedb;Trusted_Connection=Yes;"
tdf.SourceTableName = "dbo.Kunden"
CurrentDb.TableDefs.Append tdf

Damit bist Du zukunftsfähig.
Und sicher.

Tabelle: MDB vs. ACCDB vs. SQL Backend

Feature	MDB (alt)	ACCDB (neu)	SQL Backend
Verschlüsselung	schwach	AES (128 Bit)	serverseitig
Mehrbenutzerfähigkeit	gering	mittel	hoch
Dateigröße	max. 2 GB	max. 2 GB	theoretisch unbegrenzt
Rechteverwaltung	keine	keine	rollenbasiert
Stabilität bei Netzwerkausfall	schlecht	etwas besser	sehr gut

Mein Setup bei Altbeständen mit .MDB

Bereich	Maßnahme
Erste Analyse	per Dir-Suche auf .mdb + Zugriffstest
Codeprüfung	nach Declare, DAO, ADO
Migration	ACCDB + ODBC-Verknüpfung auf SQL Server
Sicherheit	Windows-Ordnerrechte + SQL-Rollen
Logging	Trigger + Änderungsprotokoll in SQL

MDB läuft. Aber nicht mehr lang. Und nicht mehr sicher.

Wenn Du noch .mdb im Einsatz hast,
ist jetzt der Zeitpunkt für den Wechsel.
Bevor es kracht.
Oder verschlüsselt wird – aber nicht von Dir.