All the problems I've ever seen manifested themselves immediately
upon attempting to open the MDB. And I've been doing this for
about ten years now.
Exactly. I've never lost a single line of code from a decompile. And
I decompile *a lot*. I believe that the fact that I decompile
frequently makes it safer, in fact, since the potentially corrupting
crud never has a chance to accumulate.
Also I probably have read all the postings in the past ten years
in the newsgroups on this topic. (I have a filter to watch all
postings with the word decompile in them.) I do not recall any
instances of decompile causing later problems although of course
that would be hard to determine cause and effect.
If decompile corrupts your VBA project, it's going to show up the
first time you try to compile it, unless it's some kind of super
smart corruption that corrupts only a small part of the VBA project
that is completely self-contained and somehow doesn't get compiled
until later.
That may actually be completely impossible since Access 2000, given
the monolithic save model.
Think of a decompile as cleaning out compiled code. Which it
does. That's an operation that either works or doesn't work. No
partial activities.
But corruption would usually involve a loss of the canonical code.
If that were to somehow happen in a completely self-contained
manner, theoretically it could go undetected.
But, theoretically, my apartment could be hit by a meteorite before
I finish posting this.
Also note that after you decompile, compile and compact you will
very likely notice a substantial decrease in the size of the FE
MDB. One of mine went from 10 Mb to 6 Mb. And you will probably
notice a substantial improvement in startup times.
Or not.
The size thing is the key that tells you the decompile has worked,
but you need to check it before you recompile.
For what it's worth, here are the steps:
1. close your MDB.
2. back it up.
3. open your Decompiling instance of Access (I have a shortcut on
the desktop that launches Access with the /decompile argument).
4. open your MDB in that instance of Access with the SHIFT key
depressed (to prevent startup code from running).
5. close that instance of Access.
6. open a new *non*-decompile instance of Access.
7. open your MDB with the SHIFT key (to prevent startup code from
running and thus, silently recompiling your decompiled code).
8. compact your MDB (be sure to hold down the SHIFT key to prevent
startup code from running when Access reopens the MDB after the
compact).
[This is the point at which you'd check the size to see that it's
smaller than before you decompiled, because this is the point at
which the compiled p-code has been discarded and all the unused data
pages recovered]
9. now compile your code.
10. compact once more.
It's crucial to remember two things:
1. be sure to hold down the SHIFT key when opening your database in
order to prevent startup code from running. If you forget at any
point in the process, you might as well start over.
2. be sure to *never* continue using the same instance of Access
that you launched with the /decompile switch.