Decompile Before Deployment
Before deploying my Access applications, I like to strip them down to their bare bones.
I don't compile my Access applications before I distribute them. In fact, I do the exact opposite. I decompile them.
Publishing front-end updates
The final step before I publish a front-end update is to run a decompile, compact, and repair operation on my .accdb file. The command looks like this:
"C:\Path\To\msaccess.exe" MyFrontEnd.accdb /decompile /compact /repair"Publish" is an intentionally vague term that could mean one of several different things:
- Uploading the .accdb file to a shared network folder
- Packaging the .accdb file into an executable setup file
- Distributing the .accdb file directly to end users via PDQ Deploy
Why decompile?
Decompiling the front-end file has two benefits:
- Reduces the size of the .accdb
- Speeds up the initial opening time on systems with different Access versions
Size reduction
Decompiling an .accdb file strips out the so-called "P-Code." This is intermediate code that acts as a bridge between the original source code and processor-level machine code. The p-code is optimized to run within the current Access environment (Access version, bitness [32 vs. 64], etc.). This code gets created alongside the source code, which means that it takes up space.
Faster initial launch
When Access first opens an .accdb file it checks to see if there is any existing p-code. If there is, it then checks to see if that p-code is compatible with the current operating environment.
"When VBA modules get compiled in Access, the compiled code is very much dependant on the VBA p-code parser library. Unfortunately there are a few variants of this library..."
- Wayne Phillips at EverythingAccess.com
If the p-code is compatible, great! But if not, then Access has to strip the p-code from the file and recreate new p-code in its place. Since the p-code is packed into the blob field of an internal table, this is not a terribly fast process. With a large enough application, this process of dropping and recompiling the p-code causes a noticeable slowdown.
By stripping out the p-code prior to distribution, we cut out the first two steps of the process: checking compatibility and dropping the p-code. This does slow things down slightly on systems where the user is running an identical version of Access as the developer. That's because if the existing p-code is compatible, then Access has nothing else to do.
In the environments where most of my applications run, though, my users are running a variety of different Access environments. So, for me, decompiling by default tends to yield the best results.
Compact and repair
Following the decompile, the compact step reclaims the vacated space where the p-code once lived. The same goes for any local temporary tables that I recently emptied. In nearly fourteen years of working with Access, from Access 2000 through Access 365/2019, the compact and repair operation has never caused a problem or corruption that I can recall.
That said, I wouldn't advise that you kill the msaccess.exe process in the middle of a repair and compact operation. I have no idea whether the .accdb file would survive fully intact, but I'm not about to run enough tests to find out for sure. Suffice it to say the repair and compact operation is safe enough that I run it frequently without thinking twice.
Image by MichaelGaida from Pixabay
