Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.
Manchmal treten in Access-Datenbanken nicht erklärbare Fehler auf. Die Datenbank stürzt immer an der gleichen Stelle ab, scheinbar ohne dass es eine Ursache dafür gibt. Oder man hat einen Haltepunkt gesetzt und wieder entfernt und der Code wird aber immer noch an der Stelle des Haltepunkts angehalten. Solche und andere Fehler können wir mit der Komprimieren und Reparieren-Funktion nicht beheben, auch wenn der Name dies suggeriert. Es ist vielmehr noch ein kleiner zusätzlicher Schritt notwendig, nämlich das Dekompilieren des Codes. Dazu gibt es eine Befehlszeilenoption mit dem Namen /decompile. Dieser Beitrag zeigt, wie Sie eine Datenbank, die Probleme macht, gegebenenfalls selbst retten können.
Probleme in Access-Datenbanken
In Microsoft Access-Datenbanken können verschiedene Probleme auftreten, für die es scheinbar keine Erklärung gibt:
- Bei Haltepunkten wird der Code auch nach dem Entfernen der Haltepunkte immer wieder angehalten.
- Codezeilen werden nicht ausgeführt.
- Formulare werden nicht geöffnet oder Access stürzt direkt ab.
Ursache könnte sein, dass bei Fehlern oder Abstürzen notwendige Informationen nicht in Systemtabellen geschrieben werden oder es werden Informationen geschrieben, die nicht mehr da sind – zum Beispiel die erwähnten Geister-Haltepunkte.
Die Lösung: Dekompilieren
Um diese Probleme zu beheben, reicht das Komprimieren/Reparieren allein nicht aus. Dazu ist ein weiterer Schritt nötig, nämlich das sogenannte Dekompilieren. Access verwendet eine kompilierte Version des VBA-Codes, da dieser schneller ist als der unkompilierte. Dieser wird beim Dekompilieren komplett verworfen. Der Code wird also in seinen ursprünglichen Zustand zurückversetzt. Öffnen wir die Datenbank danach erneut, wird der Code wieder kompiliert. Fehlerhafte oder inkonsistente Objekte werden somit aus dem kompilierten Code entfernt.
Dekompilieren allein reicht aber auch nicht aus, ein anschließender Aufruf des Befehls Datenbank komprimieren und reparieren vervollständigt den Prozess jedoch nach unseren Erfahrungen.
Achtung: Sicherheitskopie anlegen!
Bevor wir inoffizielle Methoden wie das Dekompilieren einer Datenbank nutzen, legen wir natürlich eine Sicherheitskopie der Datenbankdatei an. Das können wir einfach im Windows Explorer durch Markieren der Datei und anschließendes Betätigen der Tastenkombinationen Strg + C und Strg + V erledigen.
Alternativ kann man dies auch von Access aus erledigen – über den Befehl Speichern unter im Datei-Menü. Hier finden wir die Option Datenbank sichern (siehe Bild 1). Der Vorteil dieser Methode ist, dass diese automatisch das aktuelle Datum an den Dateinamen anhängt.
Bild 1: Sichern als Backup
Eine Datenbank dekompilieren
Das Dekompilieren kann nicht von Access aus gestartet werden. Wir können die zu dekompilierende Datenbank jedoch auf eine bestimmte Art und Weise öffnen, um dies zu erledigen. Dazu benötigen wir einen Aufruf über die Eingabeaufforderung. Diese starten wir durch Eingabe von cmd in das Suchen-Feld von Windows.
"C:\Program Files (x86)\Microsoft Office\root\Office16\MSACCESS.EXE" "C:\...\Decompile.accdb" /decompile
Dazu geben wir als Erstes den Pfad zur Datei MSAccess.exe ein. Dieser lautet für Windows 11 mit Access 365 in der 32-Bit-Version beispielsweise:
"C:\Program Files (x86)\Microsoft Office\root\Office16\MSACCESS.EXE"
Diesen Pfad finden wir per VBA mit dem folgenden Befehl:
SysCmd(acSysCmdAccessDir) C:\Program Files (x86)\Microsoft Office\root\Office16\
Der zweite Teil ist der Pfad der zu kompilierenden Datenbankdatei. Der dritte Teil ist der Parameter namens /decompile.
Beim Aufruf mit diesem Befehl wie in Bild 2 wird scheinbar einfach nur die Datenbank geöffnet. Im Hintergrund wurden aber die eingangs erwähnten Schritte durchgeführt.
Bild 2: Aufruf über die Kommandozeile
Hier sind allein die Ergebnisse bezüglich des Speicherplatzes der Datei auf der Festplatte:
- Vor dem Komprimieren und Reparieren: 54.016 MB
- Nach dem Komprimieren und Reparieren: 52.608 MB
- Nach dem Dekompilieren: 52.608 MB
- Nach dem erneuten Komprimieren und Reparieren: 43.136 MB
[
Dazu sein angemerkt, dass die meisten Tabellen in einen SQL Server ausgelagert sind – daher war kein großer Unterschied beim ersten Komprimieren und Reparieren zu bemerken. Das wir beim anschließenden Dekompilieren, Komprimieren und Reparieren fast 20% der Dateigröße verlieren, zeigt jedoch, wieviel Ballast sich im Laufe der Zeit ansammelt. Bei einer anderen oft genutzten Datenbank ergab sich folgendes Bild:
- Vor dem Komprimieren und Reparieren: 16.384 MB
- Nach dem Komprimieren und Reparieren: 9.736 MB
- Nach dem Dekompilieren: 9.740 MB
- Nach dem erneuten Komprimieren und Reparieren: 7.436 MB
Hier war die Verteilung etwas anders. Es zeigt sich jedoch: Dekompilieren und Komprimieren/Reparieren lohnt sich bei oft verwendeten Datenbanken allein bezüglich des belegten Speicherplatzes.
Dekompilieren per Batch-Datei
Nun ist es etwas umständlich, den oben erwähnten Befehl immer wieder in die Eingabeaufforderung hineinzuschreiben. Das können wir auch vereinfachen. Der erste Weg ist, diesen Befehl in eine Batch-Datei zu schreiben, die wir einfach per Doppelklick aufrufen können. Diese legen wir als einfache Textdatei im gleichen Verzeichnis wie die Datenbankdatei an. Dann fügen wir die gleiche Zeile hinzu, die wir schon oben verwendet haben (siehe Bild 3).
Bild 3: Batch-Datei zum Starten des Kompiliervorgangs
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
Testzugang
eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel
diesen und alle anderen Artikel mit dem Jahresabo