Error you can't step into

[Bruce Maston]

Hi,

I have a bug that is driving me crazy. When Access 2K is running at "full
speed," you get a run time error that is "down stream" somewhere from where
the problem is, and when you open up the debug window the message is
essentially meaningless.

On the other hand, when you go into the debug mode and step through the
program one F8 at a time, you don't get the bug.

I had this same problem in the past (first in Excel and then in Access) and
I discovered that the cause was variable declared as integer that should be
declared as long. Apparently as the number assigned to the integer variable
gets larger, it does "something" that triggers strange behavior, even though
the value of the variable does not exceed the allowable value.

By trial and error I discovered that another potential cause of this problem
is a SQL statement in ADO or a SQL statement as a ControlSource where you
have called it too many times. Once you get to the "with rst" statement, the
code wants you to do as many things as you can using that one rst, rather
than jumping back and forth with Set rst = New ADODB.Recordset.

I give this long preamble for anyone who has encountered this, as some of
these suggestions may solve your problem. But I've still episodically
getting a runtime error message, and I'm wondering (a) if there is any sort
of log file or debugging technique that exposes these types of problems or
(b) whether there are other causes of this behavior I should analyze for.

Thank you.

 

[Robert Morley]

These types of errors sound very much like you have a corrupt VBA project.
Try decompiling the project and see if that corrects the behaviour. To
decompile, click on Start, Run, then enter:

<full path to MSAccess.EXE> /decompile <full path to your database>


Rob

 

[Bruce Maston]

I believe I found the source of this bug, and I'll describe it here for
anyone with a similar problem. My application calls to a sub routine in the
module from various spots, and this sub routine updates data in a recordset
through ADO. I noticed that in all other locations where this sub routine
was called, the end of the event procedure containing the call left me on the
same form.

However, the procedure with the error had a command on the next line after
the call to doCmd.Close. This closes the form and returns to an underlying
form. I moved the call out of this form and the bug went away. So
apparently the machine gets "confused" if there is a line to close a form
right after you do an ADO recordset.