Deze post is bedoeld om wat historische achtergronden en informatie te geven over deze ongedocumenteerde commandoregel-switch in msaccess.exe. Om het te gebruiken, draai je gewoon:
msaccess /decompile <je databasenaam>
en dat is alles. Maar wat doet het eigenlijk?????
VBA EN DE 11 COMPILATIETOESTANDEN
Er zijn intern inderdaad 11 verschillende compilatieniveaus tussen ongecompileerd en geheel gecompileerd, zoals in een MDE. Als je objecten dirty maakt decompileer je het project, maar het dirty maken van Module1 verwijdert niet alle "gecompileerde" informatie over bijvoorbeeld Module2 of Form1. De exacte niveaus zijn onmogelijk te bepalen tenzij je bron- en debugsymbolen hebt voor VBA, en zelfs dan is het waanzinnig moeilijk... laten we het er dus maar op houden dat de ja/nee vraag "is het gecompileerd?" veel subcategorieen onder het NEE-antwoord heeft die in wezen betekenen dat het niet is gecompileerd, maar sommige stukken wel zo'n beetje.
P-CODE VERSUS CANONIEKE TEKST
Je code wordt opgeslagen in twee vormen, beide een Stream-object in de opslag(en) van het project. Een vorm is de canonieke tekst waar je naar kijkt en die je kunt bewerken en zo, de andere is de gecompileerde versie van de code die draait. VBA moet altijd compileren voordat het kan draaien, dus in een draaiende applicatie vind je altijd p-code. En tenzij je een MDE draait (waar de canonieke code uitgestript is) heb je altijd ook de canonieke tekst. Elke keer dat VBA denkt dat de gecompileerde code niet correct is (zoals wanneer je iets verandert of het binaire formaat verandert, wat tot nu toe alleen het gavel is tijdens betacycli), zal het de module "decompileren" en dan weer compileren vanuit de canonieke tekst.
ACCESS BETA'S: BINAIRE FORMATEN ENZ.
Mensen die de betatests gedaan hebben voor Access 95, 97 en/of 2000 zullen zich de zaken rond de binaire formaten herinneren. Van versie naar versie werden veranderingen aangebracht in VBA of de Access OM, waardoor oude gecompileerde code incorrect werd. Gewoonlijk was een crash het beste wat je kon verwachten. Om dit op te lossen werd er wat werk verricht om op een globale manier *ALLE* code in een project te decompileren, zodat er geen risico was voor incorrecte code die zou crashen.
**********
Dit is de enige reden dat de flag er is. De commandoregel-switch is niet gedocumenteerd omdat er nooit een wijziging is in het binaire formaat behalve tijdens beta's en in interne versies... dus er is geen reden om iets te documenteren waarvan het nooit de bedoeling was dat het gebruikt zou worden.
**********
MAAR er zijn wat duidelijke voordelen, bijeffecten waarvan mensen gebruik hebben gemaakt:
1) BIJEFFECT: CORRUPTE PROJECTEN
Als bijeffect heb je nu een mogelijkheid om corrupte projecten te hanteren! De canonieke tekst is namelijk nooit corrupt, het is altijd een of ander gecompileerd stuk van een project, zoals een module of meestal de type-informatie van een formulier of rapport. Door in het algemeen aan Access te vertellen dat het gecompileerde gedeelte weggegooid moet worden, kun je afkomen van het verkeerde stukje code. Dit is nu het soort reparatie dat afgerekend zou hebben met de oude Access95 vba232 paginafouten en andere problemen waar Access van het einde van een vtabel afliep en crashte, en van tig andere probleempjes. Dit is waarom PSS deze flag bekend maakte... als een project corrupt is, is dit de beste manier om het niet-corrupt te maken.
2) BIJEFFECT: PROJECTGROOTTE
Men heeft ontdekt dat het voorkwam dat een object gedecompileerd werd, waarin het Stream-object van de opslag keurig ongeldig werd gemaakt, maar tot wees werd gemaakt en achtergelaten in de opslag, en later niet werd verwijderd. Er zijn veel applicaties die gebruik maken van gestructureerde opslag die zulke problemen hebben in hun afvalverzameling... VBA/Access is er eentje van, dat is alles. Uiteindelijk zullen deze wees-streams bijdragen tot het opzwellen van het project. Mensen hebben opgemerkt dat een geheel gecompileerde applicatie meer ruimte innam dan dezelfde volledig gecompileerde applicatie waarbij alle objecten waren geimporteerd in een nieuwe database... en dat is precies waar we het hier over hebben. Zoals je misschien hebt geraden levert de /decompile-switch, die *alle* streams die gecompileerde code bevatten ongeldig maakt, effectief werk bij het opruimen van het afval en het verwijderen van verweesde streams. Dus zal een /decompile /compact zorgen voor de kleinst mogelijke database.
RISICO'S BIJ HET DECOMPILEREN: WAAROM JE HET NIET CONSTANT MOET GEBRUIKEN
Als je nadenkt over het mechanisme, vertrouw je erop dat de canonieke tekst altijd helemaal valide is, en je vertrouwt erop dat het mogelijk is een gecompileerde toestand volledig terug te draaien. Als er op een van deze gebieden een probleem is, zal /decompile een goed werkend project veranderen in een gatenkaas. En terwijl dergelijke bugs niet zouden moeten voorkomen... is het onmogelijk een /decompile-bug te laten optreden zonder /decompile te gebruiken. Ze hebben gewoon deze commandoregel-switch, die nooit voor gebruik bedoeld was, niet uitgebreid getest... en dat hoefden ze eigenlijk ook niet te doen.
DUS ONTHOUD ALSJEBLIEFT dat dit een zeer krachtige techniek is die is toegevoegd om redenen die niets te maken hebben met de redenen waarom jij het misschien wilt gebruiken. Het kan je helpen om een hopeloos corrupt project te redden. Gebruik het echter met mate, want je kunt van de regen in de drup raken door deze switch te gebruiken op projecten die het niet nodig hebben.
IS HET NIET KAPOT, PROBEER HET DAN NIET TE MAKEN.
