Die 64-Bit-Version von Access sollten Sie schon deshalb nicht nutzen, weil diese ActiveX-Steuerelemente wie das TreeView-, das ListView- oder das ImageList-Steuerelement nicht unterstützt. Aber es gibt noch weitere Gründe: Zum Beispiel könnte es Probleme bei der Verwendung von API-Funktionen geben. Manchmal bleibt einem Entwickler allerdings keine anderen Möglichkeit, weil etwa am Arbeitsplatz nur die 64-Bit-Version vorliegt oder aber der Kunde mit dieser Version arbeiten muss. Der vorliegende Beitrag liefert Informationen, wie Sie nicht kompatible VBA-Anweisungen für die Zielversion anpassen müssen und wie Sie programmieren müssen, um die 32-Bit- und die 64-Bit-Version gleichermaßen zu bedienen.
Unterschiede zwischen Access 32-Bit und Access 64-Bit
Warum entsteht das in der Einleitung beschriebene Dilemma überhaupt und was ist mit 32-Bit-Version und 64-Bit-Version überhaupt gemeint
Hierbei beziehen wir uns zunächst auf das Betriebssystem. Wenn Sie ein 32-Bit-Betriebssystem nutzen, kann dieses maximal 2 hoch 32 Bytes Arbeitsspeicher adressieren, also ca. 4.096 Megabyte. Bei einem 64-Bit-Betriebssystem kann ein Arbeitsspeicher von 2 hoch 64 Byte adressiert werden – dies wird noch eine Weile ausreichen.
Wer also mehr als vier Gigabyte Arbeitsspeicher in seinem Rechner verbaut hat und sich wundert, dass davon nur vier angezeigt werden, fährt also vermutlich noch ein 32-Bit-Betriebssystem.
Möchten Sie herausfinden, wie viel Arbeitsspeicher Sie nutzen und ob Sie ein 32-Bit- oder ein 64-Bit-Betriebssystem nutzen, können Sie dies über die Systemsteuerung ermitteln. Unter Windows 7 etwa klicken Sie dazu auf Start|Systemsteuerung und dann auf System. Es erscheint der Dialog aus Bild 1, dem Sie die notwendigen Informationen entnehmen können. In diesem Fall handelt es sich um ein 64-Bit-System mit acht Gigabyte Arbeitsspeicher.
Bild 1: Hinweise auf Arbeitsspeicher und Betriebssystem in den Systemeinstellungen von Windows
Office mit 32-Bit und 64-Bit
Damit kommen wir zum Thema Office und somit auch zu Access. Access 2010 etwa wird standardmäßig in der 32-Bit-Variante installiert.
Wer Access 64-Bit wünscht, muss dies explizit bei der Installation angeben. Warum das Weil es sehr viele externe Tools und Steuerelemente für Access in der 32-Bit-Version gibt. Würden Sie Access in der 64-Bit-Version installieren und versuchen, ein mit der 32-Bit-Version etwa von VB6 entwickeltes Add-In zu starten, führt dies zu einem Fehler.
Das Gleiche gilt, wenn Sie etwa ein 32-Bit-ActiveX-Steuerelement wie das TreeView-Steuerelement verwenden möchten – mehr dazu weiter unten.
Einfache Lösung
Wenn Sie eine neue Office-Version installieren, können Sie diese und anderen Probleme auf einfache Art und Weise umschiffen: Installieren Sie einfach die 32-Bit-Variante. Windows in der 64-Bit-Variante bietet eine Kompatibilitätsumgebung namens WOW64, mit der Sie 32-Bit-Anwendungen wie in diesem Fall Office und Access ganz normal ausführen können.
In diesem Fall wird Office nicht in dem dafür vorgesehenen Verzeichnis C:Program FilesMicrosoft OfficeOffice15 installiert, sondern etwa unter C:Program Files (x86)Microsoft OfficeOffice15.
Probleme mit ActiveX-Steuerelementen
Das vermutlich kritisch-ste Problem, das bei der Nutzung von Access in der 64-Bit-Version auftaucht, sind ActiveX-Steuerelemente, die nur in der 32-Bit-Version verfügbar sind.
Wir haben testweise eine frische Datenbank unter Access 32-Bit mit einem TreeView-Steuerelement versehen. Wenn Sie diese Datenbank unter Access 64-Bit öffnen, löst dies zunächst die Meldung aus Bild 2 aus.
Bild 2: Der Verweis auf die Datei MSCOMCTL.ocx kann unter Access in der 64-Bit-Version nicht gefunden werden.
Wenn Sie diese Meldung ignorieren und dann das Formular mit dem TreeView-Steuerelement öffnen, erhalten Sie die Meldung aus Bild 3.
Bild 3: Der Container mit dem TreeView-Steuerelement ist leer.
Was tun Nun: Es gibt keine 64-Bit-Version dieses Steuerelements, also können Sie nur zur 32-Bit-Version von Access wechseln oder eine Alternative für das TreeView-Steuerelement suchen.
Probleme mit mde/accde unter Access 64-Bit
Wenn Sie eine .mde– oder .accde-Datei unter Access in der 32-Bit-Version erzeugt haben, können Sie diese nur mit der entsprechenden Access-Version öffnen. Wenn Sie etwa eine 32-Bit-accde-Datei unter Access in der 64-Bit-Version öffnen, erhalten Sie die Fehlermeldung aus Bild 4. In diesem Fall besteht Hoffnung: Wenn Sie Zugriff auf die unkompilierte Version der Datenbankdatei haben, können Sie diese unter der 64-Bit-Version von Access kompilieren und die .mde/.accde-Datei dann unter Access in der 64-Bit-Version nutzen.
Bild 4: Fehler beim öffnen einer .mde- oder .accde-Datei, die mit Access in der 32-Bit-Version erstellt wurde
Probleme mit API-Deklarationen
Ein weiteres Problem tritt auf, wenn Sie API-Funktionen, die mit der 32-Bit-Version von Access funktionieren, unter der 64-Bit-Version einsetzen möchten. Wir schauen uns dazu die GDI-/OGL-Bibliothek von Sascha Trowitzsch an, die eine Menge API-Funktionen verwendet, und wollen diese für die 64-Bit-Version lauffähig machen.
Wenn Sie das Modul mdlOGL0710 unter Access 2013 in der 64-Bit-Version öffnen, erhalten Sie einige rot markierte Zeilen wie in Bild 5. Der erste Schritt, um die API-Deklarationen für die 64-Bit-Version nutzbar zu machen, liegt im Hinzufügen eines einfachen Schlüsselworts, und zwar PtrSafe. Dieses Schlüsselwort fügen Sie unmittelbar hinter der Declare-Anweisung der API-Funktion ein, sodass etwa die erste in der Abbildung sichtbare Funktion wie in Bild 6 aussieht.
Bild 5: Fehlerhafte API-Deklarationen
Bild 6: Hinzufügen des Schlüsselworts PtrSafe
Auf diese Weise statten Sie nun alle API-Funktionen mit diesem Schlüsselwort aus. Die Suchen/Ersetzen-Funktion des VBA-Editors ist dabei eine willkommene Erleichterung: Ersetzen Sie zunächst Declare Function durch Declare PtrSafe Function und dann Declare Sub durch Declare PtrSafe Sub – klicken Sie dabei jeweils auf Alle ersetzen (siehe Bild 7).
Bild 7: PtrSafe per Suchen/Ersetzen hinzufügen
Sollten sich noch weitere nicht kompatible API-Deklarationen finden, können Sie diese durch Betätigen des Menübefehls Debuggen|Kompilieren von auffinden. Es erscheint dann die Meldung aus Bild 8.
Bild 8: Meldung, wenn beim Debuggen noch inkompatible API-Deklarationen gefunden werden
Damit wären schon einmal die Probleme mit der Variablendeklaration behoben.
Probleme mit Variablentypen
Nach diesem Problem folgt auch gleich das nächste – wenn auch nicht offensichtlich. Dazu betätigen wir nochmals den Debuggen|Kompilieren von .
In unserem Beispiel meldet Access nun Fehler beim Kompilieren: Typen unverträglich und markiert einen Parameter der API-Funktion GdipCreateBitmapFromFile (siehe Bild 9). Hier wird offensichtlich eine Funktion namens StrPtr verwendet, um der Funktion die Adresse der Variablen sFileName zu übermitteln.
Bild 9: Datentyp-Fehler
Was geht hier schief Schauen wir uns die Funktion StrPtr an, indem wir das Kontextmenü zu diesem Befehl öffnen und den Eintrag Definition auswählen. Dies führt zunächst zur Fehlermeldung aus Bild 10.
Bild 10: Problem beim Anzeigen der Funktion StrPtr
Das ist aber kein Problem: Wir aktivieren im Objektkatalog mit einem Klick auf den Eintrag Verborgene Einträge anzeigen des Kontextmenüs die Anzeige der verborgenen Elemente.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo