Wenn plötzlich alles „Declare“ schreit

Die Umstellung auf Office 64-Bit kommt oft nicht geplant.
Plötzlich hat jemand das neue Office 365 installiert.
Und Deine Access-App?
Schmeißt Fehler wie Fehler 48: DLL-Ladefehler oder Die Deklaration ist ungültig.

Klassiker: API-Calls, falsch deklarierte Pointer, fehlende PTRSAFE.

Ich zeig Dir, wie ich die Migration sauber mache – ohne Wochen im Debugger zu sitzen.

Warum 64-Bit jetzt wichtig ist

• Microsoft empfiehlt 64-Bit bei allen Neuinstallationen
• Viele Systeme mit viel RAM laufen besser
• COM-Add-ins und Office-Automatisierung werden auf 64-Bit angepasst
• 32-Bit wird nicht verschwinden – aber Du musst mit beiden Varianten rechnen

Kurz: Neue Kunden haben fast immer 64-Bit.
Du brauchst Code, der beides kann.

Schritt 1: Welche Version ist installiert?

Public Function Ist64BitOffice() As Boolean
    #If Win64 Then
        Ist64BitOffice = True
    #Else
        Ist64BitOffice = False
    #End If
End Function

Oder direkt prüfen:

MsgBox Application.OperatingSystem & vbCrLf & Application.Version

Schritt 2: API-Deklarationen anpassen

Jede API-Funktion muss PtrSafe sein.
Und alle Long-Zeiger → LongPtr.

Beispiel alt (funktioniert nur in 32-Bit):

Declare Function GetTickCount Lib "kernel32" () As Long

Neu (kompatibel mit beidem):

#If VBA7 Then
    Declare PtrSafe Function GetTickCount Lib "kernel32" () As Long
#Else
    Declare Function GetTickCount Lib "kernel32" () As Long
#End If

Noch besser:

#If VBA7 Then
    Private Declare PtrSafe Function GetCursorPos Lib "user32" (lpPoint As POINTAPI) As Long
#Else
    Private Declare Function GetCursorPos Lib "user32" (lpPoint As POINTAPI) As Long
#End If

Und Long → LongPtr bei Zeigern:

#If VBA7 Then
    Private Declare PtrSafe Function SetTimer Lib "user32" ( _
        ByVal hWnd As LongPtr, ByVal nIDEvent As LongPtr, _
        ByVal uElapse As Long, ByVal lpTimerFunc As LongPtr) As LongPtr
#End If

Schritt 3: ActiveX-Steuerelemente prüfen

Viele alte Steuerelemente (z. B. TreeView, CommonDialog, MSFlexGrid) laufen nicht unter 64-Bit.
Dann knallt’s beim Öffnen des Formulars.

Prüfen:

• Menü „Extras → Verweise“
• Register „Steuerelemente“ → nicht installierbare Komponenten erkennen
• Ersatz suchen: Modernere Controls oder native Alternativen

Tipp: TreeView aus MSComctlLib ist nicht 64-Bit-tauglich.
Alternative: ListBox mit Rekursion oder WebView2 als Baumstruktur mit HTML.

Schritt 4: Access-Add-ins, DLLs, EXE

Wenn Du externe DLLs aufrufst, brauchst Du auch davon 64-Bit-Versionen.
Sonst kommt Fehler 53 (Datei nicht gefunden) oder Fehler 48 (DLL nicht ladefähig).

Gilt auch für:

• externe .NET-Wrapper
• COM-Komponenten
• Shell-Execute-Calls

Prüfen:

Shell "C:\Programme\MeinTool64.exe", vbNormalFocus

Schritt 5: Kompatibler Code für beide Welten

Ich nutze #If VBA7 Then und #If Win64 Then, um selektiv anzupassen.

#If VBA7 Then
    Private Declare PtrSafe Function CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _
        (ByRef Destination As Any, ByRef Source As Any, ByVal Length As LongPtr) As LongPtr
#Else
    Private Declare Function CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _
        (ByRef Destination As Any, ByRef Source As Any, ByVal Length As Long) As Long
#End If

Damit läuft der Code unter 32- und 64-Bit.

Tabelle: Häufige Fehler beim Wechsel auf 64-Bit

Mein Setup für Migrationen auf 64-Bit Access

Access läuft auch unter 64-Bit – aber nur, wenn Du den Code darauf vorbereitet hast.

Wenn es kracht, liegt’s selten an Access. Meist an alten Deklarationen, vergessenen DLLs und zu viel Copy & Paste aus 2002.

Mach’s sauber.
Dann läuft’s.
Auch in 64-Bit.