Wenn der Code noch aus der Windows-98-Zeit stammt

VBA läuft.
Oft auch noch 20 Jahre später.
Aber genau das ist das Problem.
Denn was läuft, wird nicht angefasst.
Und irgendwann fällt’s Dir auf die Füße.

Ich zeig Dir, wo’s kritisch wird –
und wie ich alte VBA-Projekte modernisiere,
ohne gleich alles umzubauen.

Risiko 1: Veraltete API-Aufrufe

Alte Declare-Statements aus der 32-Bit-Zeit
bringen Dir unter 64-Bit Office direkt Fehler.

Beispiel (falsch unter 64-Bit)

Declare Function GetUserNameA Lib "advapi32.dll" (ByVal lpBuffer As String, nSize As Long) As Long

Korrekt mit 64-Bit-Unterstützung

#If VBA7 Then
    Private Declare PtrSafe Function GetUserNameA Lib "advapi32.dll" (ByVal lpBuffer As String, ByRef nSize As Long) As Long
#Else
    Private Declare Function GetUserNameA Lib "advapi32.dll" (ByVal lpBuffer As String, ByRef nSize As Long) As Long
#End If

Funktioniert auf beiden Plattformen.
Aber nur, wenn Du es so schreibst.

Risiko 2: Fixed Strings und Variant-Spam

Klassiker aus Access 97-Zeiten:

Dim sText As String * 50
Dim Ergebnis

Problematisch für Speicher, Kompatibilität und Performance.

Empfehlung

• Keine Fixed-Length-Strings mehr
• Typisieren: Dim Ergebnis As String

Risiko 3: Keine Fehlerbehandlung

Alte Projekte bestehen oft nur aus:

On Error Resume Next

Oder gar keinem Error-Handling.
Dann passiert beim Absturz – nichts.
Und Du suchst Stunden.

Besser:

On Error GoTo Fehler

' dein Code

Exit Sub

Fehler:
    MsgBox "Fehler: " & Err.Number & vbCrLf & Err.Description, vbCritical

Noch besser: Logging in Tabelle oder Datei.

Risiko 4: Zu viele globale Variablen

Public KundenID As Long

Klingt harmlos.
Aber wird schnell unübersichtlich.
Und bei gleichzeitiger Nutzung (Frontend + mehrere Nutzer): kritisch.

Empfehlung

• Globale Variablen vermeiden
• Stattdessen TempVars, Formulare oder Parameter verwenden
• Oder Klassen nutzen

Risiko 5: Kein Unicode, kein UTF-8

Viele alte Projekte können kein ä, ö, ü
oder stolpern bei Exporten mit Umlauten.

Beispiel: Open ... For Output As #1

Lösung:

• Bei Text-Export explizit Encoding angeben (z. B. mit ADODB.Stream)
• Beim Speichern UTF-8 verwenden:

Sub ExportUTF8()
    Dim stream As Object
    Set stream = CreateObject("ADODB.Stream")
    stream.Charset = "utf-8"
    stream.Open
    stream.WriteText "Müller & Söhne"
    stream.SaveToFile "C:\temp\export.txt", 2
    stream.Close
    Set stream = Nothing
End Sub

Risiko 6: Kein Versionsmanagement

Alte Projekte haben keinen Plan,
wer wann was geändert hat.

Mein Vorgehen:

• Bei Start prüfen:

If CurrentProject.Properties("Version") <> "2.4.3" Then
    MsgBox "Falsche Version.", vbCritical
    Application.Quit
End If

• Änderungslog in separater Tabelle führen
• Optional: Git mit ACCDB-to-Text-Export nutzen (z. B. mit msaccess-vcs-addin)

Tabelle: Alt vs. Neu im VBA-Code

Alt (unsicher)	Neu (empfohlen)
Declare ohne PtrSafe	#If VBA7 Then Declare PtrSafe
Variant überall	Typisierte Variablen
On Error Resume Next	On Error GoTo Fehler + Protokollierung
String * 100	Dim sText As String
Open "file.txt"	ADODB.Stream mit Encoding
Public ID As Long	Übergabe über Parameter oder Klasse

Mein Setup zur Codehygiene in Access-Projekten

Maßnahme	Werkzeug / Technik
Fehlerhandling	Einheitliche Fehler:-Blöcke in jedem Modul
Kompatibilität prüfen	Kompilierung in 64-Bit, PtrSafe testen
Unicode/Export	ADODB.Stream für alles mit Text
Versionsprüfung	eigene Property oder Tabelle
Codeanalyse	MZ-Tools oder Rubberduck VBA

Alte VBA-Projekte sind wie Oldtimer. Sie fahren – aber Bremsen, Gurte und TÜV fehlen.

Wenn Du sie nicht modernisierst, riskierst Du irgendwann nicht nur Ausfälle – sondern auch Ärger mit Sicherheit, Kompatibilität und Nutzern.

Mach’s wie ich: Nach und nach. Ohne Big Bang. Aber mit Plan.