Access /Decompile – Was hat es damit auf sich?

von Philipp Stiefel, ursprünglich veröffentlicht am 01.03.2022, zuletzt aktualisiert am 01.03.2022

Wenn du in einem Access-Projekt unerklärliche Fehlermeldungen bekommst, insbesondere wenn du versuchst, deinen VBA-Code zu kompilieren, oder wenn Microsoft Access beim Ausführen deiner Anwendung oder bestimmter Funktionen abstürzt, besteht die Möglichkeit, dass deine Access-Datei beschädigten VBA-Code enthält.

Es ist nicht wirklich der VBA-Code beschädigt, sondern der „Maschinen“-Code, in den dein VBA-Code kompiliert wurde.

VBA-Code kompilieren

Wenn du dein VBA-Projekt mit dem Befehl Debuggen – Kompilieren ... aus dem Menü in der VBA-Umgebung kompilierst, übersetzt der VBA-Compiler den gesamten VBA-Code in deinem Projekt in P-Code. – P-Code („Pseudocode“ oder „Portable Code“) ist ein Zwischencode, der zwar Maschinencode ist, aber nicht für eine reale physische Computerarchitektur, sondern für einen abstrakten virtuellen Computer. Er kann sehr schnell in den echten, nativen Maschinencode des Computers übersetzt werden, auf dem die VBA-Anwendung gerade läuft.

Theoretisch könnte dies ein binärer Prozess sein. Am Anfang gibt es nur den VBA-Code in seiner kanonischen Textdarstellung, die du im VBA-Editor siehst, und überhaupt keinen kompilierten Code. Dann wird der Code kompiliert und neben deinem VBA-Code gibt es dann auch den vollständig kompilierten P-Code für das gesamte Projekt.

In der Praxis ist dies jedoch kein binärer Zustand. Wie du wahrscheinlich bemerkt hast, kann dein Code einen Kompilierfehler haben, der verhindert, dass ein Teil des Codes kompiliert wird, aber gleichzeitig kannst du andere Teile deines Projekts ausführen. Das Ausführen von Code in deinem Projekt erfordert, dass er kompiliert wurde. In diesem Szenario wird also ein Teil deines Projekts in einen lauffähigen Zustand kompiliert, während ein anderer Teil des Projekts aufgrund von Fehlern im Code nicht kompiliert werden kann.

Der Compiler kann einzelne Module kompilieren und andere ignorieren. Dies geschieht, wenn du ein neues Modul erstellst, Code schreibst und dann den neuen Code ausführst, ohne das gesamte Projekt explizit zu kompilieren. Der Compiler kompiliert dann nur das eine Modul (und seine Abhängigkeiten), das erforderlich ist, um den Code auszuführen, den du jetzt ausführen möchtest. – Fazit: Der kompilierte Zustand des Codes ist nicht homogen für das gesamte Projekt, sondern nur für jedes Modul.

Aber das ist noch nicht alles. Das Kompilieren von Code aus kanonischem Text (der von einem Menschen geschriebene Code) zu Maschinencode, der von einem Computer ausgeführt werden kann, ist normalerweise ein mehrstufiger Prozess. Beispielsweise wird Code in der Programmiersprache C nacheinander von einem Präprozessor, einem Compiler, einem Assembler und schließlich einem Linker verarbeitet, um eine ausführbare Datei zu erstellen. Dabei werden Zwischenstände des Codes zwischen Klartext und Maschinencode gespeichert. Soweit ich weiß, hat Microsoft niemals Informationen über die Interna des VBA-Kompilierungsprozesses veröffentlicht. Nichtsdestotrotz ist davon auszugehen, dass es auch hier mehrere Zwischenzustände des Codes gibt.

Das Fazit: Vom reinen Nur-Text-Code bis zum vollständig kompilierten Code sind mehrere Schritte erforderlich. Dabei können viele Dinge schief gehen und dazu führen, dass manche Teile des unvollständig kompilierten Codes in einen Zustand geraten, der bei der Verarbeitung zu unerwartetem Verhalten führt. Das von unsinnigen Fehlermeldungen bis hin zum Absturz von Access reichen.

Umso sinnvoller ist es, das VBA-Projekt explizit mit dem Befehl „Debuggen“ – „Kompilieren ... “ zu kompilieren. Wenn das erfolgreich war, wurde der gesamte Code erfolgreich kompiliert und es besteht kein Risiko einer Beschädigung aufgrund einer teilweisen Kompilierung mehr.

Dekompilieren

Um Probleme mit (teilweise) kompiliertem VBA-Code in einer Access-Datenbank zu beheben, hat das Microsoft Access-Team den /decompile-Befehlszeilenschalter für MSACCESS.EXE entwickelt. Ursprünglich war dies nur als Microsoft-internes, undokumentiertes Feature für das Support-Team gedacht, aber irgendwann wurde es in der Access-Community bekannt und wurde zu einem wertvollen Tool zur Rettung beschädigter Access-Datenbanken.

Der Begriff Dekompilieren erweckt den Anschein, dass der Prozess den kompilierten P-Code aus deinen Datenbankdatei als Ausgangspunkt verwendet und den Kompilierungsprozess umkehrt, um die Klartextversion des VBA-Codes zu rekonstruieren. Das ist nicht der Fall! Eine normale (mdb/accdb) Access-Datenbank enthält sowohl den kompilierten Code als auch den ursprünglichen reinen VBA-Code. Wenn du Access mit dem /decompile-Schalter ausführst, wird Access einfach angewiesen, die ganzen verschiedenen Zustände des kompilierten Codes zu verwerfen und wieder von vorne zu beginnen (d. h. Ihren VBA-Code).

Wenn der obige Absatz nicht klar genug war: Du kannst den /decompile-Schalter nicht verwenden, um den ursprünglichen VBA-Code aus einer kompilierten mde/accde-Access-Datei zu rekonstruieren. Beim Erstellen einer mde/accde-Datei wird der VBA-Code in P-Code kompiliert, der P-Code wird in der Datei gespeichert und der ursprüngliche VBA-Code entfernt. Es gibt also nichts Sinnvolles, was der Befehl /decompile mit einer solchen kompilierten Access-Datei tun könnte. Und für den beabsichtigen Verwendungszweck von /decompile das ist auch gar nicht erforderlich. Sobald der Code erfolgreich vollständig kompiliert wurde, besteht kein Risiko einer Beschädigung in den Zwischenzuständen und somit keine Notwendigkeit, ihn zu dekompilieren, um eine solche Beschädigung zu beseitigen.

Dekompilieren in der Praxis

Schauen wir uns zum Abschluss an, wie /decompile tatsächlich verwendet wird.

Da es sich um einen Befehlszeilenschalter handelt, musst du eine Befehlszeile erstellen, um Access auszuführen und deine Datenbankdatei zu öffnen. Das sieht dann so aus:

Eventuell musst du den Pfad zur MSACCESS.EXE und natürlich den zu deiner Datenbankdatei anpassen. Dann kannst du die obige Befehlszeile mit dem Windows-Befehlszeilenprozessor (cmd.exe) ausführen.

Der Einfachheit halber erstelle ich normalerweise eine Verknüpfung im Arbeitsverzeichnis des jeweiligen Access-Projekts mit einer solchen Befehlszeile für die Access-Datei dieses Projekts. Dadurch ist das Dekompilieren mit einem Doppelklick leicht zugänglich.

Bitte beachte: Der /decompile Schalter war nur als internes Tool bei Microsoft gedacht. Es ist nicht offiziell dokumentiert und wahrscheinlich nicht so gründlich getestet wie andere Funktionen. Es ist immer eine gute Idee, deine Datenbankdatei zu sichern, bevor du sie dekompilierst.

Share this article: