Here is an old text by Michael Kaplan (
www.trigeminal.com - no longer public):
Information about the switch decompile
This post is intended to provide some historical background and info on this undocumented msaccess.exe command line option.
To use them, just type:
msaccess /decompile
and that's it. But what exactly is happening here?????
VBA AND THE 11 STAGES OF COMPILATION
Internally, there are actually 11 different compilation levels between decompiled and fully compiled, as can be found in an MDE, for example. If you modify objects (i.e. trigger the "dirty" state), then decompile the project. But if e.g. module1 gets dirty, that doesn't mean that all "compiled" info about module2 or form1 is removed. The exact level can only be determined using VBA source and debugging symbols, and even then extremely difficult... so we take it for granted here that the yes/no answer to "is the project compiled?" has many subcategories on the no side which basically mean it is not compiled but some parts of it are in a similar state.
P-CODE AND CANONIC TEXT
Your code is stored in 2 forms, each of which is a Stream object in the project store(s). One form is the canonical text that you can read and edit etc., the other is the compiled version of the code that is executed. VBA must always compile before execution, so you will always find p-code in a running application. And unless you're using an MDE (from which the canonical code has been removed), you'll always find the canonical text in there as well. Whenever VBA thinks the compiled code is invalid (e.g. if you make a change or the binary format changes, which has only been done in beta test runs so far), it will "decompile" the module and recompile it based on the canonical text.
ACCESS BETAS: BINARY FORMATS, ETC.
Access 95, 97 and/or 2000 beta testers will remember the problems with the binary format. From build to build, changes were made in VBA or in the Access OM that invalidated the old compiled code. Usually the result was a crash. To fix this, work was being done on a global way to decompile *ALL* the code that is in a project so you don't run the risk of any invalid code causing a crash.
**********
This is why the switch exists and only for this reason. The command line option is undocumented because - except for betas and internal builds - there is never a change in the binary format... so there's no reason to document something that was never meant to be used.
**********
BUT there are some positive side effects that people take advantage of:
1) SIDE EFFECT: CORRUPT PROJECTS
One of the side effects is the ability to handle corrupt projects! It's never the canonical text that gets corrupt, it's always a compiled part of the project, like a module or most commonly the type info of a form or report. Anyway, by globally telling Access to throw out the compiled code, you also get rid of the broken bits of code. This type of fix would cure the old Access95-VBA232 page faults and other problems where Access would go past the end of a vtable and crash, as well as a plethora of other small problems. That's why the PSS first announced this switch publicly...if a project goes corrupt, that's simply the best way to cure it.
2) SIDE EFFECT: PROJECT SIZE
There are cases where an object is decompiled and while the Stream object is correctly invalidated in memory, it is left orphaned in memory and then not cleaned up later. There are many applications that use structured storage and have such a problem with their garbage collection... So VBA/Access is just one of many. Over time, these orphaned streams will add to the project bloat. People have noticed that a fully compiled application takes up more space than the same application when all objects are imported into a new database and then fully compiled... and that's the point here. As you might have guessed, the /decompile switch invalidates *all* streams that contain compiled code, effectively garbage-collecting and removing those orphaned streams. Therefore /decompile /compact gives the smallest possible size for a database.
RISKS OF DECOMPILE: WHY YOU SHOULD NOT USE IT ALL THE TIME
When considering the mechanism, always rely on perfectly fine canonical text and the ability to completely invalidate the compiled state. If there is a problem with either of those two things, /decompile will turn a well-functioning project into cottage cheese. Bugs like this shouldn't happen... but there's no way a bug can happen to /decompile if you don't use /decompile. The command line option, which was not intended to be used, was simply not tested extensively... why should it?
SO PLEASE REMEMBER that this is a very powerful technique that was added for reasons that have nothing in common with those you might want to use it for now. She can help you salvage an otherwise hopelessly corrupt project. But use it sparingly, because you could also make things worse if you constantly use the switch on projects that don't need it.
IF SOMETHING IS NOT BROKEN, DO NOT FIX IT.
