Wartung & Modernisierung: Wie kann ich eine alte, komplexe Access-Datenbank übernehmen und modernisieren?

Du kennst das:
Ein Kollege ist weg. Die Access-Datenbank ist alt. Und keiner weiß genau, wie sie funktioniert.

Jetzt darfst Du ran.

Ich zeig Dir hier, wie Du eine komplexe Alt-Datenbank analysierst, übernimmst und schrittweise modernisierst – ohne gleich alles wegzuwerfen.

1. Erste Analyse: Wie schlimm ist es wirklich?

Bevor Du irgendwas änderst: Überblick verschaffen.

Fragen, die ich mir immer zuerst stelle:

• Gibt es ein separates Backend (Split-DB)?
• Gibt es Makros – und wenn ja, wie viele?
• Wie viel VBA-Code ist im Spiel?
• Wie viele Objekte sind es insgesamt? (>200? Dann wird’s spannend.)
• Ist das Ding produktiv oder „nur intern“?

Und: Gibt’s noch jemanden, der weiß, was das Ding eigentlich macht?

2. Objektbestand sichern

Bevor Du auch nur einen Button klickst:

• Kopie machen (immer lokal)
• Alles exportieren in Textdateien: Tabellen, Formulare, Module

Tipp: Nutze dafür „SaveAsText“ aus dem Immediate-Fenster:

SaveAsText acForm, "frmKunden", "C:\Export\frmKunden.txt"

Für Module:

Application.SaveAsText acModule, "modTools", "C:\Export\modTools.txt"

Oder gleich ein kleines Tool schreiben, das alle Objekte durchgeht.

3. Frontend und Backend sauber trennen

Viele Altprojekte laufen noch als Monolith. Das ist schlecht.

Teile sofort auf:

• Backend: Nur Tabellen
• Frontend: Alles andere

Nutze Linked Table Manager, um die Verknüpfung einzurichten. Und wenn möglich: Backend auf Netzlaufwerk oder SQL Server migrieren (später).

4. Code strukturieren und durchforsten

Erste Schritte:

• Option Explicit überall einschalten
• Makros in VBA umwandeln
• Globale Variablen identifizieren (und reduzieren)

Schreibe Dir Helferfunktionen, um alle Module systematisch durchzugehen:

Public Sub ZeigeAlleProzeduren()
    Dim mdl As Object
    For Each mdl In Application.VBE.VBProjects(0).VBComponents
        Debug.Print mdl.Name
    Next
End Sub

Dann: Aufteilen. Alles, was mehrfach vorkommt → ins Modul modCommon.

5. Benennungen normalisieren

Du willst:

• tblKunden, qryKundenAktiv, frmKunden, rptKundenübersicht
• Keine Form1, Query2, Button3_Click()

Mach’s lesbar. Für Dich. Für alle danach.

6. Daten prüfen

Viele Altprojekte haben:

• leere Felder, wo Pflichtdaten sein sollten
• doppelte Datensätze
• veraltete Spalten (z. B. Faxnummer)

Erzeuge Abfragen zur Prüfung. Beispiel:

SELECT * FROM tblKunden WHERE Email IS NULL

Oder:

SELECT Email, COUNT(*) FROM tblKunden GROUP BY Email HAVING COUNT(*) > 1

7. Benutzeroberfläche modernisieren

• Labels sinnvoll setzen
• Steuerelemente umbenennen (txtName, cboOrt, cmdSpeichern)
• Farben vereinheitlichen
• Navigation logisch gestalten

Und: Unnötige Buttons rauswerfen. Weniger ist mehr.

8. TempVars statt globaler Variablen

Viele Altprojekte benutzen versteckte Felder oder globale Variablen für Benutzerkontext.
Heute besser:

TempVars.Add "Benutzerrolle", "Admin"

Und dann überall verfügbar – auch in Abfragen.

9. Dokumentation beginnen (auch wenn’s nervt)

Mach wenigstens:

• eine Übersicht über Formulare & Tabellen
• eine Beschreibung der zentralen Geschäftslogik
• eine Liste aller kritischen Abfragen

Wenn Du später etwas umbaust, bist Du froh.

10. Modernisierung in Etappen

Du musst nicht alles neu machen.
Aber:

• Ersetze veraltete DAO/ADO-Mischungen
• Lagere hartcodierte Werte aus (z. B. Statuscodes in tblLookupStatus)
• Bereite langfristig den Umstieg auf Access + SQL Server oder Power Platform vor

Und: Dokumentiere jede Änderung. Auch wenn Du denkst, Du merkst sie Dir. Tust Du nicht.

Fazit

Eine alte Access-DB zu übernehmen ist kein Kindergeburtstag.
Aber mit Ruhe, Struktur und ein bisschen Ehrgeiz geht’s.

• Erst analysieren, dann anfassen
• Nichts ohne Sicherung
• Modernisierung ist ein Prozess, kein Big Bang

Und wenn’s zu wild wird: lieber neu bauen.
Aber auf Basis dessen, was Du jetzt wirklich verstanden hast.