[AccessD] Decompile

I received a question on decompile and just thought I'd forward the question and my response.  My 
take on the question was "when access opens a database" rather than "do you specifically do this for 
us every time".

Jump in if I missed or am off on anything.

 > Also - please remind me, but every time you open a db, you are running the compile/decompile 
routine - correct?

No.  In fact you have to have a special decompile switch in the hot link to tell Access to decompile 
the databases opened by that instance of Access.  Once you have that you have to specifically open 
Access using that link in order to decompile the database.  AFAICT that open instance will decompile 
every database it opens until you close that instance and open Access without the /Decompile switch.

I usually set up a decompile link on my desktop, then drag and drop it to my quick launch toolbar. 
Do you have one or do you want me to help you set one up?

This really only applies to a database with visual basic code in it, because that is what /decompile 
affects. /Decompile does not affect macros, queries, or tables.  It affects forms, reports and 
modules.  Once decompiled, the database needs to be compiled again or it will run slower as the user 
executes decompiled source code.

Just a FYI, the English language Visual Basic "source code" statements in modules are compiled into 
what is known as P-Code.

http://en.wikipedia.org/wiki/P-Code

P-Code is an intermediate step between the English language VB and the actual machine instructions 
(AKA Machine Code) that the CPU can execute.  So Access "compiles" the VB into P-Code and then an 
interpreter "interprets" the P-Code to turn it into machine code.

Access has special buffers where it permanently stores the P-Code.  When you /Decompile the 
database, those buffers are "flushed" or emptied out.  If you specifically "Compile" the code, every 
single piece of the VB source code in every module, report and form is "compiled" to P-Code and 
stored in these buffers.  If you do NOT specifically "compile" the VB source code, then the source 
is "compiled" the first time it is executed.

So for example, when a form opens it would need to be "compiled" and the P-Code stored in the buffer 
before the form can open.  After it is opened that first time, the P-Code is already there in the 
buffer and it is never "compiled" again.  If code in a form calls code in a module, then ALL of the 
code in that module must be compiled (not just the specific function called by the form) because 
Access loads an entire module into memory, not just the called functions.

If you do not specifically compile the entire database (Debug / compile) this compilation process 
takes a certain amount of time and can slow down the "first time" opening of a form or report.  On 
modern (fast) computers it is certainly not a huge amount of time but it is there none the less.

Just as a point of interest (and nothing we can do about it) an Interpreter does exactly that, it 
"interprets" the P-Code each and every time a line of code is executed.  A true compiler takes the 
P-Code and turns it directly into Machine Code such that it never has to be interpreted again (until 
the source changes).

Access (and the .Net languages as well BTW) uses a P-Code Interpreter, not a true compiler so a 
"Compiler" compiles (one time) the source code into P-Code, and then an Interpreter interprets the 
P-Code every time it sees the code.  Each time a line of source code is executed, the P-Code 
interpreter is busily interpreting P-Code for us.

Now it can happen that the P-Code in the buffers get corrupted somehow.  The "somehow" is very 
nebulous, none of us know how, but it can happen.  So the /Decompile tells Access "throw out the 
P-Code".  It does NOT tell Access to recompile the code.  Not sure why that is but it doesn't.  Thus 
  if you /decompile, you should manually recompile.  Strictly speaking you so not have to, it just 
makes things speedier for the user.

So there ya go, more than you ever wanted to know about Decompile.
-- 
John W. Colby
www.ColbyConsulting.com