Option explicit crash

  • Thread starter Thread starter Chris
  • Start date Start date
C

Chris

Hi all,
Been banging my head off the wall for a couple of days
now. I was going to post a question here but I figured it
out eventually. So I've decided to share what I found in
case it helps someone searching in the future.
My database was opening when holding down the shift
key but crashing otherwise. It crashed consistently on
opening my user logon form (which was in the startup).

The only change I made was to add the line Option Explicit
at the top and it then worked fine.

The form had 3 small functions and none of them used any
variables without declaring them first. I don't know why
this fixed the problem but it did and I no longer get
the 'send report to microsoft' screen on loading the form.
It seems to be a pretty nasty crash for such a small
ommision. Why don't they just prevent you from not using
Option Explicit or make it the default setting for all new
modules? Anyway, I hope this helps someone

Regards,
Chris
 
Chris:

I suspect that it wasn't so much the content of the edit, but rather that fact
that you performed an edit that made the difference. You might have some VBA
corruption that just happened to "unscramble" itself enough after your edit to
clear up the problem. If you experience problems again, you might consider
"decompiling" the application file in an attempt to remove any such corruption.
There is an *unsupported* "decompile" switch (available in Access 97, 2000, 2002
and, presumably, 2003) that can be used to help correct this situation, but this
is more of a "last resort" in that there is some risk to the file as described
in http://www.trigeminal.com/usenet/usenet004.asp?1033 (so ... work with a copy
of the file). Further information is available at
http://www.databasecreations.com/DatabasePerformanceTips.pdf and
http://www.granite.ab.ca/access/decompile.htm. The procedure I use when
implementing this is as follows:

1) BACK UP YOUR MDB FILE!
1) BACK UP YOUR MDB FILE! (I meant it the first time <g>)
2) Compact the MDB.
3) Implement the "/decompile" as described in the articles I referenced.
(Access 2000, and later, don't provide the confirmation dialog that
existed in Access 97, but the decompile will still take place.)
4) Open Access normally and compact the MDB again to clean up.
5) Compile and save.
6) Compact again before testing/using.

:-)
 
Thanks Bruce

I always wanted to Decompile because I knew I had quite a
bit of garbage/unused code. My db shrank from 12.8meg to
7.8 meg. So far the testing is going well

Thanks again

Jim
 
Thanks for the advice. Couldn't download that permformance
PDF for some reason but I'll try again later. I had a look
through my code an realised that there were quite a few
compilation errors that had never been looked at. For the
last year I've been adding code and ignoring old code that
is no longer useful. I assumed that it compiles everything
on demand and thus I had no need to compile the code
manually. Another advantage is that I can now export to
MDE for my users. Previously I was giving them MDB's with
the runtime version of access. I'm hoping this will
improve performance even more. It's clear that there is
still loads to learn.

Regards,
Chris
 
Back
Top