VBA IDE Corrupts db in 2002

  • Thread starter Thread starter Jim Shaw
  • Start date Start date
J

Jim Shaw

BlankFor the last 6 months, I've been experiencing Access "unable to
continue" messages, due to (I believe) corruption of the database. To get
going again, I've had to import the corrupted database objects (tables,
forms, reports, modules, etc.) into a new database (2000) and then convert
it to 2002 format. When this message is received, the VBA IDE window is
always open or in the process of being opened.

Are many of you experiencing this problem or, is it just me?
Has Microsoft developed a fix for this yet?

Thanks
Jim
 
Jim, any chance you are editing the code in break mode, i.e. while the form
is open (not in design view)? IME, that corrupts the database.

Do you leave all your VBA windows open, so that the editor has to load them
all? If anything at all is wrong, that could cause a crash.

If you have any VBA add-ins, they may also contribute to the problem.

Once it goes bad, a Decompile sometimes helps. Decompile a copy of the
database by entering something like this at the command prompt while Access
is not running. It is all one line, and include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

For a list of the other things to check, see:
Preventing Corruption
at:
http://members.iinet.net.au/~allenbrowne/ser-25.html
 
Allen Browne said:
Jim, any chance you are editing the code in break mode, i.e. while the form
is open (not in design view)? IME, that corrupts the database.

Yes, I do that occasionally. Like when I get an execution time error and
the debugger takes me into VBA/IDE. It hasn't crashed then, but perhaps it
is getting corrupted there. I'll change my ways on this. Last time I
crashed, it was during a "Repair & Compact" process; the VBA/IDE was open by
mistake when I initiated that.
Do you leave all your VBA windows open, so that the editor has to load them
all? If anything at all is wrong, that could cause a crash.

No, having them all open is too confusing. I will have a few (3-4) open if
I'm doing a search & replace at the Project level and (1-2) when I'm cutting
and pasting code.
If you have any VBA add-ins, they may also contribute to the problem.

I don't have any of these. Have not learned about them yet.
Once it goes bad, a Decompile sometimes helps. Decompile a copy of the
database by entering something like this at the command prompt while Access
is not running. It is all one line, and include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

This is new to me; I'll give it a try. Is this different (in terms of
cleaning things up) from importing my application into a new db?
For a list of the other things to check, see:
Preventing Corruption
at:
http://members.iinet.net.au/~allenbrowne/ser-25.html
Thanks for the link, I'll go there.

Thanks for all of your comments
Jim
 
Inline

Jim Shaw said:
This is new to me; I'll give it a try. Is this different (in terms of
cleaning things up) from importing my application into a new db?

Yes. An Access mdb contains 2 copies of the code: the text version (what you
view and edit), and the complied version (what actually runs). If these 2
are different, it is a form of corruption. Although importing into a new
database is a good way to handle other kinds of corruption, in this case it
can simply import the entire form and both forms of the code, so the
imported form still has the inconsistency.

The decompile addresses this issue by telling the database to throw away the
compiled version of the code. It will then recreate it from the text
version, so the inconsistency is gone. IME, the most common causes of this
kind of corruption are:
- editing in break mode (as discussed), and
- switching between versions (2000, 2002, and 2003), since each of these
uses a different binary. Therefore a decompile is useful before using a
database you developed in A2002 under A2000.
 
Back
Top