I have seen a few posts lately on how to use the undocumented /decompile
command line argument to msaccess.exe to recover databases with corrupted
compiled VBA code in them.  I have been trying this out lately on all of my
code databases:

1. Open the database in access started with the /decompile argument.
2. Compile and save all modules.
3. Compact.

An interested side effect of the decompilation (which I assume just throws
out all of the compiled VBA code) is that after doing these steps most of
the databases are reduced in size 30 - 40% from their previous compacted
size.  I have no idea why this is, does anyone else out there?  It is pretty
cool though.  I just hope I am not screwing anything up.

Alden

I have noticed the same thing. Strange...

Shayne

Hi Alden,

Is it possible that in an earlier version of your db you had modules or
code which then became redundant and were removed.

I'm just thinking that maybe Access keeps the compiled code even if you
remove the code itself. In decompiling you may have "tidied up" old
compiled code that was no longer used.

This is just a guess.

Matt.  

Right!  The mdb size should decrease if it's compacted.  Access stores both
the compiled and decompiled state code from what I understand.  /Decompile
"throws out" (like you said) the compiled state code, and this is what
results in the reduction in size.

In terms of any possible harm.... Don't think there is any.. Other than your
forms/reports etc.  loading slowly.

Dev
--
Dev Ashish (Just my $.001)
---------------
The Access Web ( http://home.att.net/~dashish )
---------------

:I have seen a few posts lately on how to use the undocumented /decompile
:command line argument to msaccess.exe to recover databases with corrupted
:compiled VBA code in them.  I have been trying this out lately on all of my
:code databases:
:
:1. Open the database in access started with the /decompile argument.
:2. Compile and save all modules.
:3. Compact.
:
:An interested side effect of the decompilation (which I assume just throws
:out all of the compiled VBA code) is that after doing these steps most of
:the databases are reduced in size 30 - 40% from their previous compacted
:size.  I have no idea why this is, does anyone else out there?  It is
pretty
:cool though.  I just hope I am not screwing anything up.
:
:Alden
:
:

Yeah but the size decrease I mention is AFTER I do a compile all modules
again after the decompile, so the compiled code is all put back in.

Alden

However, in a project that has some sort of problems such as dead space that
VBA thinks it needs, there are occasional (very occasional!) times that the
/decompile will free all space, and then the recompile has none of this dead
space afterwards.

Its not really an Access problem per se, it has to do with some basic
limitations of OLE storages and streams (I have seen OLE have the same
problem in other cases as well where queries as to the size of an OLE
storage will have it claim to be bigger than it is, yet reading out info and
writing it back fresh will make it smaller.

Michael