PDA

Vollständige Version anzeigen : Infos zum Schalter decompile


Aquarii
31.07.2003, 21:33
Hier ein interessanter Artikel zu dem Schalter decompile:


Betreff: INFO: Was es mit dem Schalter /Decompile wirklich auf sich hat.
(ursprünglich gepostet 22.5.99)

Dieses Posting soll ein wenig historischen Hintergrund und Info über diese undokumentierte Befehlszeilenoption der msaccess.exe liefern. Um sie zu verwenden, geben Sie einfach ein:

msaccess /decompile <Name Ihrer Datenbank>

und das war's schon. Aber was genau passiert hier?????

VBA UND DIE 11 STADIEN DER KOMPILIERUNG

Es gibt intern tatsächlich 11 verschiedene Kompilier-Ebenen zwischen dekompiliert und voll kompiliert, wie das etwa in einer MDE zu finden ist. Wenn Sie Objekte verändern (d.h. den Zustand "dirty" auslösen), dann dekompilieren Sie das Projekt. Wenn aber z.B. Modul1 dirty wird, heißt das nicht, dass die ganze "kompilierte" Info über Modul2 oder Formular1 entfernt wird. Die exakte Ebene ist nur mit Source- und Debugging-Symbolen von VBA zu ermitteln, und auch dann nur äußerst schwierig... deshalb nehmen wir es hier als gegeben hin, dass die Ja/Nein-Antwort auf "ist das Projekt kompiliert?" viele Unterkategorien auf der Nein-Seite hat, die im wesentlichen bedeuten, dass es nicht kompiliert ist, aber einige Teile davon in einem ähnlichen Zustand sind.

P-CODE UND KANONISCHER TEXT

Ihr Code wird in 2 Formen gespeichert, jede davon ist ein Stream-Objekt im (in den) Projektspeicher (n). Die eine Form ist der kanonische Text, den Sie lesen und bearbeiten können etc., die andere ist die kompilierte Version des Codes, die ausgeführt wird. VBA muss vor der Ausführung immer kompilieren, daher werden Sie in einer laufenden Anwendung immer P-Code finden. Und wenn Sie nicht eine MDE verwenden (aus der der kanonische Code entfernt wurde), werden Sie stets auch den kanonischen Text darin finden. Immer wenn VBA meint, der kompilierte Code sei ungültig (z.B. wenn Sie eine Änderung vornehmen oder das binäre Format sich ändert, was bisher nur in Betatestläufen gemacht wurde), wird es das Modul "dekompilieren" und es auf Basis des kanonischen Textes neu kompilieren.

ACCESS BETAS: BINÄRE FORMATE, ETC.

Betatester von Access 95, 97 und/oder 2000 werden sich an die Probleme mit dem binären Format erinnern. Von Build zu Build wurden Änderungen in VBA oder im Access-OM vorgenommen, die den alten kompilierten Code ungültig machten. Normalerweise war das Ergebnis ein Crash. Um das zu fixen wurde an einer globalen Möglichkeit gearbeitet, den *GANZEN* Code zu dekompilieren, der sich in einem Projekt befindet, damit man nicht Gefahr läuft, das irgendwelcher ungültiger Code einen Absturz verursacht.

**********
Aus diesem Grund gibt es den Schalter und nur aus diesem Grund. Die Befehlszeilenoption ist undokumentiert, weil es - außer bei Betas und internen Builds - niemals eine Änderung des binären Formates gibt... deshalb gibt es keinen Grund, etwas zu dokumentieren, dass nie dazu gedacht war, verwendet zu werden.

**********

ABER es gibt einige positive Nebeneffekte, die die Leute nutzen:

1) NEBENEFFEKT: KORRUPTE PROJEKTE

Einer der Nebeneffekte ist die Möglichkeit, korrupte Projekte zu behandeln! Es ist niemals der kanonische Text, der korrupt wird, es ist immer ein kompilierter Teil des Projektes, wie ein Modul oder am häufigsten die Typinfo eines Formulares oder Berichtes. Indem man Access ganz global sagt, es möge den kompilierten Code wegwerfen, wird man jedenfalls auch die kaputten Teile des Codes los. Mit dieser Art von Fix konnte man die alten Page Faults von Access95-VBA232 kurieren und andere Probleme, bei denen Access über das Ende einer Vtable hinausging und abstürzte, ebenso wie eine Unmenge anderer kleiner Probleme. Das war der Grund, warum der PSS erstmalig diesen Schalter öffentlich bekannt gab... wenn ein Projekt korrupt wird, ist das einfach der beste Weg, es zu kurieren.

2) NEBENEFFEKT: PROJEKTGRÖSSE

Es gibt Fälle, in denen ein Objekt dekompiliert wird und während das Stream-Objekt im Speicher korrekt ungültig gemacht wird, bleibt es verwaist im Speicher zurück und wird dann später nicht weggeräumt. Es gibt viele Anwendungen, die strukturierte Speicherung verwenden und ein solches Problem mit ihrer Müllsammlung haben... VBA/Access ist da also nur eine von vielen. Mit der Zeit tragen diese verwaisten Streams zum Aufblähen des Projektes bei. Die Leute haben bemerkt, dass eine voll kompilierte Anwendung mehr Platz verbraucht als die gleiche Anwendung, wenn alle Objekte in eine neue Datenbank importiert werden und dann voll kompiliert wird... und genau darum geht es hier. Wie Sie sicher schon vermutet haben, setzt der /decompile-Schalter *alle* Streams, die kompilierten Code enthalten, auf ungültig, macht eine effektive Müllsammlung und entfernt diese verwaisten Streams. Deshalb ergibt /decompile /compact die kleinstmögliche Größe für eine Datenbank.

RISKEN VON DECOMPILE: WARUM SIE ES NICHT STÄNDIG ANWENDEN SOLLTEN

Wenn Sie sich den Mechanismus überlegen, dann verlassen Sie sich dabei immer auf einen kanonischen Text, der völlig in Ordnung ist, und auf die Fähigkeit, den kompilierten Status komplett für ungültig zu erklären. Wenn es bei einem dieser beiden Dinge ein Problem gibt, wird /decompile ein gut funktioniertes Projekt in Hüttenkäse verwandeln. Solche Bugs sollten nicht vorkommen... aber es ist unmöglich, dass ein Bug bei /decompile passiert, wenn man /decompile nicht verwendet. Man hat die Kommandozeilenoption, die nicht zur Verwendung gedacht war, einfach nicht ausführlich getestet... wozu denn auch?

ALSO, BITTE BEDENKEN SIE, dass dies eine sehr mächtige Technik ist, die aus Gründen hinzugefügt wurde, die nichts mit denen gemein haben, aus denen Sie sie jetzt evtl. nutzen möchten. Sie kann Ihnen helfen, ein ansonsten hoffnungslos korruptes Projekt zu retten. Aber setzen Sie sie sparsam ein, denn Sie könnten die Situation auch verschlechtern, wenn Sie den Schalter bei Projekten, bei denen das nicht nötig ist, ständig verwenden.

WENN ETWAS NICHT KAPUTT IST, REPARIEREN SIE ES NICHT.

Quelle:

http://www.trigeminal.com/usenet/usenet004.asp?1031