1. Name AutoCorrect
Dirk, Name AutoCorrect (Tools | Options | General) is not the same as the
Allow AutoCorrect property of controls (which is merely spelling correction,
and does not cause corruption.)
Name AutoCorrect is a nice idea. It attempts to keep track of changes to the
name of fields and tables, so that queries, forms, and reports can still
find the affected fields after a name change. It is a performance disaster,
but more importantly it is probably the most common cause corruption in
Access 2000 and later.
Here is a short list of some of the known problems caused by AutoCorrupt:
http://allenbrowne.com/bug-03.html
The list is not up to date, i.e. some issues have been addressed, and the
many new ones have not been added, but it should be enough to give you the
idea.
2. Decompile
Access keeps 2 copies of the code in a MDB:
- the text version (what you read and edit), and
- the compiled version (binary that actually executes.)
Under some conditions, these 2 get out of sync.
Decompiling instructs Access to jettison the compiled version.
It then creates the compiled version again out of the text, and so the sync
issue is gone.
To decompile, make a backup of the database, and then enter 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"
One of the causes of this kind of corruption sees to be altering code while
it is running, e.g. editing the code of a form while the form is open (not
in design view), or editing a class module while instantiated. When you
start modifying an object, Access creates a temp copy of the object, so you
can revert to the last saved copy. At this point, it is trying to balance 4
copies of the code: the text and compiled version of the operating and
original object. It seems to get confused between these copies. When I
realized this (back in the Access 97 days), and stopped editing in break
mode, it stopped the majority of development corruptions I was experiencing.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Reply to group, rather than allenbrowne at mvps dot org.
Dirk said:
Well actually haven't taken the usual steps since I am relatively new to
(and
reluctant to use) Access. Normally I code things in .NET, Java or PHP.
Could you perhaps clarify why Name AutoCorrect could be a problem? From
what
I've seen it only seems to handle capitalisation of names which looks nice
even though VB should be case insensitive when compiling.
Haven't tried decompiling. Will give it a go and see what comes up.
Instantiation is going fine. The method in question takes no parameters so
seems safe there. Everything in the class is strong typed, no variants
anywhere so any errors should be caught if wrong variable types get
passed.
When I do pass variables, through properties for instance, I pass
primitive
types by value and objects by reference. Not using variants does pose a
bit
of a problem when working with null values from the database, but for the
objects I've worked with setting variables to Empty has done the job so
far,
but I digress.
I'll try your suggestions tomorrow morning and see if that helps and get
back to you with the results. Hope this issue can be figured out.
Allen Browne said:
Okay, I hope others do chip in here, as I don't use class modules often -
partially because they are more unstable than other forms of VBA code -
so
anyone with experience, please comment.
I guess you have taken the usual steps, such as:
- Make sure Name AutoCorrect boxes are unchecked under:
Tools | Options | General
- Decompile, 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"
- Double-check your instantiation, and that there is no chance of
arguments
being bad (e.g. Error or Null being passed, and not passing an entire
object
to a Variant when you intended only a value.)
Sorry, Dirk: that's a lame list. The bit that surprises me is that it
still
crashes without any call to the class module, i.e. even if nothing is
instantiated. Does it crash even if the class module is removed (working
on
a copy of course)?
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Reply to group, rather than allenbrowne at mvps dot org.
Dirk said:
First of all. Sorry for the lack of detailed information.
1) I am running Access 2003 on Windows XP (both fully updated).
2) The form does not have a sub form
3) Yes, the crash does not occur when this particular call is commented
out.
Other methods in this custom class are called without any problem. And
yes,
the class is fully custom so not subclassed off of Form, nor does it
implement any other classes.
The more detailed error message I get when firing up Visual Studio to
debug
is:
Unhandled exception at 0x6502F489 in MSACCESS.EXE: 0xC0000005:
Access violation reading location 0x00000058.
Which happens executing this instruction in vbe6.dll:
mov ecx, dword ptr [ebx + 58h], which implies ebx being equal to 0.
:
Dirk, please tell us more about this issue.
What version of Access is this?
Does the form have a subform?
Do the crashes cease if you comment out the calls to your custom class
module (which I assume is something other than the module of the
form)?
Hopefully others can jump in with suggestions when we have further
info.
I am having a consistent Access Application crash happening when a
form calls a certain method on a custom written class. After
debugging
and going through the code step by step I found that the crash
actually
occurs calling the method rather than running any code inside said
method.
Debugging Access itself being outside of my capabilities I am
wondering
what to do next as I am rathe stuck now.
