Decompiling an A97 mdb file...

[MLH]

Can decompiling an A97 mdb result in fixing minor nasties that may be
responsible for some premature terminations of A97 (We are sorry. MS
Access 97 needs to close.... messages). I've found the following
recommendation and was wondering if any of you have used the
technique and why you did?

To decompile start Access with the /decompile switch. To do this from
windows do a Start, Run and then where it asks for the name of the
program to run type:
"c:\program files\microsoft office\office\m saccess.exe" /decompile
Make sure you include the quotes as above. Also modify the file path
if necessary to point to where msacess.exe is located (if it is
different in your installation). When Access starts select/open the
mdb you want to decompile. (the first mdb you open after starting
Access in this fashion will get decompiled). Then compact the
database (tools, Database Utilities, Compact and Repair). Then open
up any module and do a menu Debug, Compile. Then close the module.
Then compact the database again.

[Allen Browne]

Yes, decompile is a useful technique to solve a particular kind of
corruption with Access databases.

An MDB contains 2 copies of your VBA code:
- the text version (what you read and edit);
- the code version (what actually executes).

Under certain circumstances, these 2 can get out of sync, so that what is
running does not match the code you are viewing. A decompile instructs
Access to discard the compiled version. Then when you start the database
again, it recreates the compiled version out of the text, and the sync
problems are gone.

It is always good practice to back up before a decompile. If it were the
text copy that was damaged, a decompile could make things worse. In practice
this is rare (especially as you can see the problem in the text version.)
You probably want to compact immediatedly after a decompile to regain the
space that was occupied by the compiled code.

As to what causes this kind of corruption, without evidence I suspect that
editing a module while it is executing (i.e. in break mode) is a
contributing factor. When you begin editing, Access creates another temp
copy of the form and its module (so you can revert to the saved copy.) It is
now trying to balance 4 copies of the code. If this happens while the form
is open (not in design view) and the code is running, it appears that Access
gets confused between the different copies. The only evidence I have for
this is circumstantial, i.e. electing to always switch to design view before
editing prevented about 2/3 of the corruptions of this type that I
experienced.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"MLH" <CR**@NorthStat e.net> wrote in message
news:so******** *************** *********@4ax.c om...

Can decompiling an A97 mdb result in fixing minor nasties that may be
responsible for some premature terminations of A97 (We are sorry. MS
Access 97 needs to close.... messages). I've found the following
recommendation and was wondering if any of you have used the
technique and why you did?

To decompile start Access with the /decompile switch. To do this from
windows do a Start, Run and then where it asks for the name of the
program to run type:
"c:\program files\microsoft office\office\m saccess.exe" /decompile
Make sure you include the quotes as above. Also modify the file path
if necessary to point to where msacess.exe is located (if it is
different in your installation). When Access starts select/open the
mdb you want to decompile. (the first mdb you open after starting
Access in this fashion will get decompiled). Then compact the
database (tools, Database Utilities, Compact and Repair). Then open
up any module and do a menu Debug, Compile. Then close the module.
Then compact the database again.

[Lyle Fairfield]

I have but I do not.
Because I saveastext and (re) loadfromtext all my objects and I believe
this practice is superior to decompiling in cleaning out extraneous
crud and identifying errors.

The recommendation you quote is inefficient.

[Tim Marshall]

Allen Browne wrote:

Yes, decompile is a useful technique to solve a particular kind of
corruption with Access databases.

Not related to MLH's question, but I've found that in A2003 it's almost
mandatory to do this now and then druing development as bloat is so severe.

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[David W. Fenton]

"Allen Browne" <Al*********@Se eSig.Invalid> wrote in
news:43******** *************** @per-qv1-newsreader-01.iinet.net.au :

As to what causes this kind of corruption, without evidence I
suspect that editing a module while it is executing (i.e. in break
mode) is a contributing factor. . . .
I do this all the time in A97 and never experience corruption.

I think the biggest cause of code corruption is not turning off
COMPILE ON DEMAND.
. . . When you begin editing, Access creates another temp
copy of the form and its module (so you can revert to the saved
copy.) It is now trying to balance 4 copies of the code. If this
happens while the form is open (not in design view) and the code
is running, it appears that Access gets confused between the
different copies. The only evidence I have for this is
circumstantial, i.e. electing to always switch to design view
before editing prevented about 2/3 of the corruptions of this type
that I experienced.

I've never seen this kind of problem in A97.

But I always run with COMPILE ON DEMAND turned off, and decompile on
a regular basis (at the end of any extensive coding session, once or
twice a day), and always compile manually before running new code.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[MLH]

Sure sounds like logical conclusions to me, Allen. I've been guilty
on countless occasions of editing code while the module was running -
I just assumed that - because I could - it must be OK to do so. But I
can readily understand the points you've made. I think I'll adopt your
practice of editing form & report code ONLY when such objects are
in design view.
xxxxxxxxxxxxxxx xxxxxxxxxxxxxxx xxxxxxxxxxxxxxx xxxxxx
On Wed, 15 Feb 2006 23:42:15 +0800, "Allen Browne"
<Al*********@Se eSig.Invalid> wrote:

Yes, decompile is a useful technique to solve a particular kind of
corruption with Access databases.

An MDB contains 2 copies of your VBA code:
- the text version (what you read and edit);
- the code version (what actually executes).

Under certain circumstances, these 2 can get out of sync, so that what is
running does not match the code you are viewing. A decompile instructs
Access to discard the compiled version. Then when you start the database
again, it recreates the compiled version out of the text, and the sync
problems are gone.

It is always good practice to back up before a decompile. If it were the
text copy that was damaged, a decompile could make things worse. In practice
this is rare (especially as you can see the problem in the text version.)
You probably want to compact immediatedly after a decompile to regain the
space that was occupied by the compiled code.

As to what causes this kind of corruption, without evidence I suspect that
editing a module while it is executing (i.e. in break mode) is a
contributing factor. When you begin editing, Access creates another temp
copy of the form and its module (so you can revert to the saved copy.) It is
now trying to balance 4 copies of the code. If this happens while the form
is open (not in design view) and the code is running, it appears that Access
gets confused between the different copies. The only evidence I have for
this is circumstantial, i.e. electing to always switch to design view before
editing prevented about 2/3 of the corruptions of this type that I
experienced.

[MLH]

DAvid - how does one go about turning off
COMPILE ON DEMAND?