Risks of decompile

[John J.]

I want to decompile my FE to reduce its size. I've read more than once that
decompile is not without risks as it is an undocumented feature. My
questions are:
- specifically what risks are we talking about?
- is there a way to test if the decompile was succesful? Should I just test
all functionalities or can I do it another way?
Thanks you.
John

 

[Pete D.]

First make a backup, make sure it is a good backup and put it someplace
safe. Then you have no more risk than using the datafile normally ould
cause. After decompile recompile the file and then use it. If something
went wrong you'll know soon. Just keep the backup around for future needs.

 

[John J.]

Thanks Pete, see inline:

If something went wrong you'll know soon.

How would I know? What can happen?

Just keep the backup around for future needs.

The backup isn't reassuring to me. What if I notice the damage a month
later, while I have made lots of other changes to this decompile-damaged FE.
I wouldn't want to go back to the month old backup and start all over.

John

 

[Tony Toews [MVP]]

I want to decompile my FE to reduce its size. I've read more than once that
decompile is not without risks as it is an undocumented feature. My
questions are:
- specifically what risks are we talking about?
- is there a way to test if the decompile was succesful? Should I just test
all functionalities or can I do it another way?

I have once or twice in ten years had problems with it. I *always*
make a copy by using Windows Explorer, click on the file, Ctrl+C to
copy and Ctrl+P to paste.

The way I knew I had problems was that the new MDB crashed or
otherwise didn't work. It was very apparent within a second or two.

So I just deleted the current MDB, made a copy of the copy I had just
made and the decompile worked fine. No idea why one puked and the
other didn't.

I do ensure I do a decompile on a regular basis if I'm doing a lot of
work in an FE MDB or just before I ship the MDB/MDE to the clients.

Decompile or how to reduce Microsoft Access MDB/MDE size and decrease
start-up times
http://www.granite.ab.ca/access/decompile.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Rick Brandt]

Thanks Pete, see inline:


How would I know? What can happen?


The backup isn't reassuring to me. What if I notice the damage a month
later, while I have made lots of other changes to this
decompile-damaged FE. I wouldn't want to go back to the month old
backup and start all over.

If a decompile/recompile is going to damage your file it will do so by
corrupting it or by allowing an existing corruption to cause further damage.
If this happens your file will be messed up immediately. It is not the sort
of thing you will discover later on.

 

[Sylvain Lafontaine]

In all cases, you should always make a backup of your database file at
regular intervals, even without decompiling it. It's possible that a
decompilation might corrupt it but with no more chance than with any other
operation on it. Everytime you write to your database, you have a chance of
corrupting it.

 

[Tony Toews [MVP]]

How would I know? What can happen?

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.

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.

The backup isn't reassuring to me. What if I notice the damage a month
later, while I have made lots of other changes to this decompile-damaged FE.
I wouldn't want to go back to the month old backup and start all over.

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.

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.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[John J.]

Thanks Rick, Sylvain, Tony!
That's excellent and reassuring info.

 

[David W. Fenton]

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.

 

[David W. Fenton]

I have once or twice in ten years had problems with it. I
*always* make a copy by using Windows Explorer, click on the file,
Ctrl+C to copy and Ctrl+P to paste.

Er, Ctrl-V to paste? Ctrl-P is the shortcut for printing, and
Windows Explorer does nothing in response to it.

Why "V"? Because "P" is already used for printing, and the "V" looks
like a caret for insertion.

These are standard commands from a set of keyboard shortcuts defined
long before Windows, and available on many different OS's and in
almost all Windows applications.

 

[John W. Vinson]

I want to decompile my FE to reduce its size. I've read more than once that
decompile is not without risks as it is an undocumented feature. My
questions are:
- specifically what risks are we talking about?
- is there a way to test if the decompile was succesful? Should I just test
all functionalities or can I do it another way?
Thanks you.
John

Do note that decompiling does not (by itself) affect the size of your
database; you must recompile and Compact and Repair in order to recover the
space.

Neither operation is perfect; to get a truly clean database with clean system
tables, you may want to create a new, empty database and Import everything
into it. Decompile first, and compile, compact and repair the new database
after importing.

 

[david]

There were some repeatable failures when you had a particular
kind of class module. Before the problem was identified, this was
just "sometimes, for some people". Since I rarely use user-defined
classes, I've never had a problem with decompile.

If you are using Class Modules, you may wish to backup before
decompiling. Since I don't, I always decompile before backup.

Since I am working in a development environment with FE/BE
database design, I make copies after making changes. If you are
working with live data, you may wish to make a copy before
making changes.

You normally test a decompile by making an MDE. If the database
opened successfully, and compiles successfully, and you don't have
any class modules, then you don't have to test that anymore.

(david)

 

[Tony Toews [MVP]]

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.

Yeah, I was thinking that but never got around typing that.

Or not.

You won't notice a substantial decrease in size or startup times if
you decompile a lot. Which you do. Others however will. See
comments on my decompile page.

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.

FWIW I've never been too rigid with these steps and its worked fine
for me.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Tony Toews [MVP]]

Er, Ctrl-V to paste? Ctrl-P is the shortcut for printing, and
Windows Explorer does nothing in response to it.

Err, umm, typo? Not a clue where P came from. You're right though
that it should be V

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Arvin Meyer [MVP]]

Merely writing to a database won't corrupt it. The corruption can possibly
occur if the write is interrupted. Even then the chance of corruption is
slight unless there is a memo data type or other OLE field in the table.
Other things can cause problems as well, so a daily (or more often) backup
is necessary. A hard drive could crash, a hacker could intentionally cause
damage, etc. A regular backup schedule is just common sense.

To put it in perspective, I've only corrupted an Access database while in
production once during a dropped connection during Replication, and once
when a machine was left on over a weekend and a painter unplugged it. I have
seen several cases of corruption at a client's site, but none in the past 5
years. I've been decompiling databases since version 97 and have never
corrupted one during a decompile. I have corrupted a few Access 2000
databases during development.

 

[David W. Fenton]

[]

Or not.

You won't notice a substantial decrease in size or startup times
if you decompile a lot. Which you do. Others however will. See
comments on my decompile page.

My quibble is with the idea that it will always be noticeable. There
is very likely always a performance improvement, but it may be too
small for a human being to detect, let alone notice without looking
for it.

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.

FWIW I've never been too rigid with these steps and its worked
fine for me.

I think that if you aren't rigid about them you might as well not
bother, because you're missing the benefit of decompiling and
compacting. There are too many cases I've seen where crud that
hasn't been removed with a compact mucks things up later on, and
that's why I think you need to be careful to do it all in the right
order every single time.

 

[David W. Fenton]

Neither operation is perfect; to get a truly clean database with
clean system tables, you may want to create a new, empty database
and Import everything into it. Decompile first, and compile,
compact and repair the new database after importing.

I'd say decompile, compact, recompile, compact. The reason is that
imports can carry crud that shouldn't be there, and the compact
insures that all the discarded code pages are removed *before* you
recompile.

 

[David W. Fenton]

If you are using Class Modules, you may wish to backup before
decompiling. Since I don't, I always decompile before backup.

I use tons and tons of class modules and decompile almost as often
as I breathe. No corruption, and that's in A97, A2K and A2K3, all of
which I program in quite regularly (all three in any given week,
though not all three every single day).

 

[John W. Vinson]

I'd say decompile, compact, recompile, compact. The reason is that
imports can carry crud that shouldn't be there, and the compact
insures that all the discarded code pages are removed *before* you
recompile.

Thanks, David - that is in fact what I do and should have said!

 

[Sylvain Lafontaine]

No sure of totally understanding what you are doing but what I'm using
myself with Access 2003 is to use all the three command line options (or
parameters): /decompile /compact /repair

It does a pretty job of decompiling and compacting in a single step.
Sometimes, I repeat it a second time just to be sure. Notice that the
documentation say that using both /compact and /repair at the same time is
now useless since A2000; however, this is not what I'm observing with Access
2003. I never tried it with A2007.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)

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.