Object invalid or no longer set error

[J]

Is there a way for me to get more specifics or to trap this error. It seems
to be happening at random times and sometimes just when the database has been
idle for a few minutes.

Any help is appreciated.

 

[John_G via AccessMonster.com]

Hi -

The are numerous possible causes of this error - mis-spelling of variable
names (using Option Explicit will usually prevent that), or referencing an
object after you have closed it are two examples. It is unlikely that error
will be "random" though. Can you post the code where the error occurs, and
indicate which line it fails at? Otherwise, ww can only guess what might be
wrong.

John

 

[J]

Hi John -

Thanks for your response. I wish I could post the code that is causing this
issue, but that's my problem, I don't know what specifically is causing the
error. Even though it's an error, if you click on OK you can continue
working. It doesn't give you the option to "debug". I also had instances
where I walked away from my pc and when I came back I had to click OK several
times to get past the error, but then I could continue on like nothing
happened. It doesn't stop any processes.

The db is fairly complex and has many tab controls and subforms. I just
don't know how to pinpoint what "object" is causing the issue.

 

[John_G via AccessMonster.com]

Hi -

It sounds as if the errors are being trapped by "On error go to..."
statements which branch to an error processing routine, which then uses
Msgbox to display err.description. This is of course good programming
practice, but it can make debugging difficult. If you are able to determine
at least the form where the errors occur, then you could comment out all the
"On error go to ..." statements and then run the application again so the
errors will not be trapped and will produce error messages with the debug
option. This will let you find out where the error is being generated
(assuming it is coming from the form code - it could also come from code in a
module).

Another technique I use to find errors is the use of debug.print statements
to track code progress.

You should perhaps do this in a copy of your database, since letting an
application fail with untrapped runtime errors can easily cause problems with
the data.

By the way, you should never assume that just because the application
continues to run after you click OK to clear the messages that it is doing
what it should; a trapped error can cause a lot of code to be bypassed,
depending on what the error processing routine does.

HTH

John

Hi John -

Thanks for your response. I wish I could post the code that is causing this
issue, but that's my problem, I don't know what specifically is causing the
error. Even though it's an error, if you click on OK you can continue
working. It doesn't give you the option to "debug". I also had instances
where I walked away from my pc and when I came back I had to click OK several
times to get past the error, but then I could continue on like nothing
happened. It doesn't stop any processes.

The db is fairly complex and has many tab controls and subforms. I just
don't know how to pinpoint what "object" is causing the issue.

Hi -

[quoted text clipped - 12 lines]

 

[Tony Toews [MVP]]

Thanks for your response. I wish I could post the code that is causing this
issue, but that's my problem, I don't know what specifically is causing the
error. Even though it's an error, if you click on OK you can continue
working. It doesn't give you the option to "debug". I also had instances
where I walked away from my pc and when I came back I had to click OK several
times to get past the error,

I wonder if you have a hidden form on a timer that is having some
troubles.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

 

[Tony Toews [MVP]]

It sounds as if the errors are being trapped by "On error go to..."
statements which branch to an error processing routine, which then uses
Msgbox to display err.description. This is of course good programming
practice, but it can make debugging difficult.

I very much like using MZTools because it has a convenient button for
creating the standard error trapping, which you can customize, but it
also includes the object name and procedure name. Of course you have
to ensure that you change the text if you rename the object or the
procedure.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/