Warum Du das Thema nicht länger schieben solltest

Office 64 Bit ist mittlerweile Standard.
Neue Rechner, neue Installationen – oft automatisch 64 Bit.
Dein 32-Bit-Access-Frontend läuft dann nicht mehr ohne Umbau.
Und zwar nicht „ein bisschen nicht“ – sondern gar nicht.

Was sich bei 64 Bit ändert

• API-Deklarationen brauchen PtrSafe
• Zeigergrößen müssen mit LongPtr angepasst werden
• ActiveX-Steuerelemente können Probleme machen
• COM-Komponenten müssen 64 Bit unterstützen

Schritt 1: Prüfen, ob Dein Code betroffen ist

Du hast nichts zu tun, wenn:

• kein Declare-Statement im Code
• kein Zugriff auf Windows-API
• keine COM-DLLs im Einsatz

Aber: Sobald API-Deklarationen auftauchen, geht der Spaß los.

' 32 Bit (falsch für 64 Bit)
Private Declare Function GetTickCount Lib "kernel32" () As Long

' 64-Bit-kompatibel
#If VBA7 Then
    Private Declare PtrSafe Function GetTickCount Lib "kernel32" () As Long
#Else
    Private Declare Function GetTickCount Lib "kernel32" () As Long
#End If

Schritt 2: Typen überarbeiten

Ersetze Long durch LongPtr, wenn’s sich um Speicheradressen handelt.
Das betrifft meistens Handles, Pointer oder Rückgabewerte von API-Calls.

#If VBA7 Then
    Dim hwnd As LongPtr
#Else
    Dim hwnd As Long
#End If

Schritt 3: COM-DLLs und ActiveX prüfen

Viele alte Steuerelemente laufen nur unter 32 Bit.
Beispiel: MSCOMCTL.OCX oder ältere PDF-Viewer.
Wenn’s rummuckt: Komponente raus oder gegen moderne Lösung tauschen.

Schritt 4: Saubere Testumgebung aufbauen

Am besten eine virtuelle Maschine mit 64-Bit-Office.
Oder Office 365 Click-to-Run in 64 Bit.

Dann:

• Kompiliere Dein Projekt mit Option Explicit
• Fange Fehler mit Debug.Print und Logging
• Laufzeit testen mit mehreren Benutzern

Schritt 5: Projekt vorbereiten

Ergänze Deine Deklarationen so, dass beide Welten unterstützt werden.
Stichwort: bedingte Kompilierung.

#If VBA7 Then
    Private Declare PtrSafe Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" ( _
        ByVal hwnd As LongPtr, _
        ByVal lpOperation As String, _
        ByVal lpFile As String, _
        ByVal lpParameters As String, _
        ByVal lpDirectory As String, _
        ByVal nShowCmd As Long) As LongPtr
#Else
    Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" ( _
        ByVal hwnd As Long, _
        ByVal lpOperation As String, _
        ByVal lpFile As String, _
        ByVal lpParameters As String, _
        ByVal lpDirectory As String, _
        ByVal nShowCmd As Long) As Long
#End If

Typenvergleich 32 Bit vs. 64 Bit

Typische Fehlerquellen

• Copy\&Paste aus alten Forumsbeiträgen
• selbst geschriebene DLLs
• Rückgabewerte ohne Prüfung
• keine Fehlerbehandlung in API-Calls

Bonus: Eigene Tools

Ich hab mir ein Makro gebaut, das alle Module scannt und Declare-Zeilen auflistet:

Public Sub ScanneAufDeclare()
    Dim comp As Object, zeile As String, i As Long
    For Each comp In Application.VBE.ActiveVBProject.VBComponents
        For i = 1 To comp.CodeModule.CountOfLines
            zeile = comp.CodeModule.Lines(i, 1)
            If InStr(zeile, "Declare") > 0 Then Debug.Print comp.Name & ": " & zeile
        Next i
    Next
End Sub

Mein Fazit

Du kannst Access nicht ewig auf 32 Bit festnageln.
Wenn Du professionell arbeitest, geh das Thema jetzt an.
Mach’s systematisch: Typen, API, COM prüfen – dann rennt Dein Code auch unter 64 Bit.
Und wenn nicht: Ich helf Dir gern beim Umbau.