Access-Datenbanken auf 64-Bit-Office umstellen

08. November 2019

Wurde bislang von Microsoft die Verwendung von 32-Bit-Office empfohlen, so gibt es inzwischen diverse » Gründe für den Umstieg auf 64-Bit-Office. Zeit, sich mit dem Thema "Access-Datenbanken unter 64 Bit" auseinanderzusetzen.

Eine einfache Datenbank-Anwendung ohne Erweiterungen durch ActiveX (OCX) und ohne API-Calls kann in der Regel ohne Änderung auf einem 64-Bit-System verwendet werden. Bei größeren Anwendungen erhält man aber vermutlich eine Fehlermeldung: "Fehler beim Kompilieren dieser Funktion. In dem Visual Basic-Modul liegt ein Syntaxfehler vor."  Die Datenbank muss also an 64-Bit angepasst werden.

Hier muss man zwei Fälle unterscheiden: Es kann ausreichen, eine Datenbank auf die Verwendung mit 64-Bit-Office umzustellen - nämlich dann, wenn sie zukünftig ausschließlich in einer 64-Bit-Umgebung laufen wird. Oder es kann notwendig sein, eine Datenbank so zu erweitern, dass sie sowohl mit einem 32-Bit- als auch mit einem 64-Bit-System läuft. Wir betrachten hier den zweiten Fall; für den ersteren kann man sich die erforderlichen Änderungen daraus ableiten.

VBA ab Office 2010 unter 32-Bit- und 64-Bit-Office

In der 64-Bit-Version gibt es den neuen Datentyp LongLong, eine 64-Bit-Ganzzahl mit Vorzeichen, also mit einem Wertebereich von -9.223.372.036.854.775.808 bis 9.223.372.036.854.775.807. Dieser Datentyp wird im 64-Bit-Office für Zeiger und Handles verwendet, insbesondere auch in API-Funktionen, welche mit einer Declare-Anweisung in Access eingebunden werden.

Um die Umstellung von Access ab 2010 auf 64-Bit zu vereinfachen, wurden zwei Konstrukte ergänzt:

  • LongPtr wird je nach System in Long (32-Bit) bzw. LongLong (64-Bit) aufgelöst. Verwendet man also "LongPtr" für Zeiger und Handles, so kümmert sich Access um den korrekten Datentyp.
  • PtrSafe gibt an, dass eine Declare-Anweisung so überarbeitet wurde, dass sie in einer 64-Bit-Umgebung ausgeführt werden kann, d.h. dass die darin verwendeten Zeiger und Handles mit LongPtr deklariert wurden.

In der Regel wird es reichen, eine Declare-Anweisung entsprechend anzupassen, z.B. wird 

Private Declare Function GetOpenFileName  Lib "comdlg32.dll" _
  Alias "GetOpenFileNameA" (pOpenfilename As OPENFILENAME) As Long

durch folgende Anweisung ersetzt:

Private Declare PtrSafe Function GetOpenFileName Lib "comdlg32.dll" _
  Alias "GetOpenFileNameA" (pOpenfilename As OPENFILENAME) As LongPtr

Man prüft also die Parameter vom Typ "Long": Falls es sich um einen Pointer handelt, wird er nun mit "LongPtr" deklariert.

Dies gilt natürlich auch für Variablen, die im VBA-Code verwendet werden und entweder Parameter oder Rückgabewerte von API-Calls enthalten, welche mit "LongPtr" deklariert wurden.

VBA-Code in verschiedenen Umgebungen

Die Schlüsselworte "LongPtr" und "PtrSafe" gibt es erst ab Access 2010. Und auch dann kann es notwendig sein, tatsächlich nach 32-Bit und 64-Bit zu unterscheiden. 

Um dieselbe Datenbank-Datei in einer alten Umgebung (also bis Office 2003), in einer 32-Bit- und einer 64-Bit-Umgebung verwenden zu können, bedienen wir uns der bedingten Compilierung, d.h. wir bauen entsprechende Weichen in den Code ein, so dass Teile des Codes jeweils nur in einer bestimmten Umgebung ausgeführt wird.

Glücklicherweise stellt Microsoft bereits passende Compilerkonstanten zur Verfügung:

  • mit VBA7 kann man zwischen Office vor bzw. ab 2010 unterscheiden
  • mit Win64 kann man zwischen 32-Bit- und 64-Bit-Office unterscheiden

So können wir nun genau differenzieren:

#if VBA7 then 
  '  Visual Basic for Applications ab Office 2010
  #if Win64 then 
     '  64-Bit-Office 
  #else 
     '  32-Bit-Office 
   #end if 
#else 
  ' Visual Basic for Applications vor Office 2010 
#end if

Nicht erschrecken, wenn unter 64 Bit plötzlich Zeilen im Code rot markiert sind: Dies bedeutet nur, dass Access in der 64-Bit-Version diesen Teil des Codes nicht versteht. Da die Zeilen aber über die bedingte Kompilierung ausgeschlossen werden, wird der Code trotzdem ohne Fehlermeldung kompiliert.

Access mit 64 Bit: Code rot markiert

ACCDE für 32-Bit und 64-Bit

Soll von der Datenbank eine ACCDE erstellt werden, so muss man in jeder Umgebung eine eigene Version erstellen, d.h. man öffnet die ACCDB unter 32-Bit-Office und erstellt eine ACCDE für die 32-Bit-Umgebung und macht dasselbe dann noch mal auf dem 64-Bit-System.

Falls man eine ACCDE in der falschen Umgebung öffnet, erhält man die Fehlermeldung: "Diese Datenbank wurde mit der 32-Bit-Version von Microsoft Access erstellt." bzw. "Diese Datenbank wurde mit der 64-Bit-Version von Microsoft Access erstellt."

ActiveX-Steuerelemente

Verwendet man ActiveX Controls (.ocx), so muss man diese Stück für Stück darauf prüfen, ob sie unter 64-Bit-Office lauffähig sind bzw. ob es eine entsprechende 64-Bit-Version gibt. Im schlechtesten Fall muss man sich nach einem Ersatz für das Steuerelement umschauen.

Maximale Größe von 2 Gigabyte

Von Microsoft haben wir keine Aussage dazu gefunden, dass in der 64-Bit-Version von Access das Limit von 2 GB Größe je ACCDB aufgehoben wurde. Zur Sicherheit haben wir es ausprobiert: Die Obergrenze von 2 GB besteht nach wie vor.

Kommentare (0)

Keine Kommentare gefunden!

Neuen Kommentar schreiben