Access /Decompile – What is that about?

by Philipp Stiefel, originally published 2022-02-01, last updated 2022-02-01

If you get inexplicable error messages in a project, particularly when you try to compile your VBA code, or if Microsoft Access crashes when you run your application or certain functionality in it, there is a chance that your Access file contains corrupt VBA code.

Well, it’s not actually the VBA code that is corrupt, but the “machine” code that your VBA code was compiled to.

Compiling VBA Code

When you compile your VBA project using the Debug – Compile ... command from the menu in the VBA environment, the VBA compiler translates all the VBA code in your project to P-Code. – P-Code (“Pseudo Code” or “Portable Code”) is an intermediate code that is machine code, but not for a real physical computer architecture, but for an abstract virtual computer. It can be very quicky translated to the real native machine code of the computer the VBA application is currently running on.

In theory, this could be a binary process. At the beginning there is only the VBA code in its text canonical text representation you see in the VBA Editor and no compiled code at all. Then the code is compiled and in addition to your VBA code there is also the complete compiled P-Code for the whole project.

In practice however, this is not a binary state. As you probably have noticed, you can have a compile error in your code that prevents some of the code from being compiled, but at the same time you can still run other parts of your project. Running code in your project requires it to be compiled. So, in this scenario one part of your project is compiled to a runnable state while another part of your project cannot be compiled due to errors in the code.

The compiler can compile individual modules while ignoring others. This happens when you create a new module, write some code, and then run the new code without explicitly compiling the whole project. The compiler then compiles only the module (and its dependencies) that are required to execute the code you want to run right now. – Conclusion: The compiled state of the code is not homogeneous for the whole project but only for each module.

But it doesn’t stop there. Compiling code from canonical text (the code you wrote) to code a computer can execute is usually a multi-step process. For example, code in the C programming language is sequentially processed by a preprocessor, a compiler, an assembler, and finally a linker to create an executable file. During this process, intermediate states of the code between plain text and machine code are stored. As far as I know, Microsoft never publicly disclosed information on the internals of the VBA compilation process. Nonetheless, it is reasonable to assume, it also involves multiple intermediate states of the code.

The bottom line is: There are many steps and many moving parts involved from pure text-only code to fully compiled code. Many things can go wrong along the way and can cause parts of the partially compiled code to get into a state that causes unexpected behavior, ranging from nonsense error messages to crashing Access, when it is processed.

This is all the more reason, to explicitly compile the VBA project use the Debug – Compile ... command. If this succeeds all the code was successfully compiled and there is no more risk of corruption due to partial compilation.

Decompile

To fix problems with (partially) compiled VBA code inside an Access database the Microsoft Access Team created the /decompile command line switch for the MSACCESS.EXE. Originally this was intended as a Microsoft-internal, undocumented feature for the support team only, but eventually it leaked out to the Access community and became a valuable tool to rescue corrupted Access databases.

The term decompile suggests that the process takes the compiled P-Code from your database file and reverses the compilation process to reconstruct the plain-text version of the VBA code. This is not the case! A normal (mdb/accdb) Access database contains the compiled code and the original plain VBA code. Running Access with the /decompile switch will simply tell Access to dispose all the various states of compiled code and start from scratch (i.e., your VBA code) again.

If the above paragraph wasn’t clear enough on this: You cannot use the /decompile switch to retrieve the original VBA code from a compiled mde/accde Access file. When creating an mde/accde file, the VBA code is compiled to P-Code, the P-Code is stored in the file, and the original VBA code is removed. So, there is nothing sensible the /decompile command can do with such a compiled file. And it doesn’t have to. Once the code was successfully compiled completely, there is no risk of corruption in intermediate states and thus no need to decompile to get rid of such corruption.

Decompile in Practice

To wrap things up, let’s look at how to actually use /decompile.

As it is a command line switch, you need to construct a command line to run Access and open your database file in turn. This simply looks like this:

You might need to adjust the path to the MSACCESS.EXE and, of course to your database file. Then you can execute the above command line from the Window command line processor (cmd.exe).

For my convenience, I usually create a shortcut in the working directory of any Access project with such a command line for the Access file of that project. This makes it readily accessible with a double click.

Please note: The decompile switch was only intended as an internal tool at Microsoft. It is not officially documented and probably not as thoroughly tested as other features. It is always a good idea to backup your database file before decompiling it.

Share this article: