Form goes into code for no apparent reason

  • Thread starter Thread starter William Oliveri
  • Start date Start date
W

William Oliveri

I have a program in MS Access where after text is entered into a field the
program goes into code and stops at the same line every time for no apparent
reason. There is no break point there and there's no problem with the code.
I can hit F8 and it continues on it's way like nothing happened. Also, this
only happens once when the application is started. After we press F8 and go
on it doesn't do it again.

Can anyone tell me what's going on here and how to stop it?


Thank you,

Bill
 
Hi, Bill.
Can anyone tell me what's going on here and how to stop it?
Click to expand...

Sounds like the debugger settings were saved the last time a break point was
set at that line of code. You can open and close the database repeatedly,
and the problem remains.

To fix it, open the database, then open the form in Form View. Press
<ALT><F11> to open the VB Editor. Click the "Reset" button on the toolbar
three times. (Answer to question I know you are going to ask: Because
sometimes twice just isn't enough.) Select the Debug menu -> Compile
<DatabaseName>, just in case the code wasn't already compiled.

Press <ALT><Q> to return to Access. Select the Tools menu -> Database
Utilities -> Compact and Repair Database to compact the database. When
finished, close the database. Open the database again and open the form in
Form View, then enter text into the field that has recently been causing the
problem. The problem should be gone because you've removed the ghost
breakpoint.

And next time you are stepping through code, don't make any changes to the
code. That's what causes the ghost breakpoints.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
 
To fix it, open the database, then open the form in Form View. Press
<ALT><F11> to open the VB Editor. Click the "Reset" button on the toolbar
three times. (Answer to question I know you are going to ask: Because
sometimes twice just isn't enough.) Select the Debug menu -> Compile
<DatabaseName>, just in case the code wasn't already compiled.
Click to expand...

Have you tried:
set a brakpoint to the invisible one
reset the brakpoint
compile

In my case (2000 and 2002) this works everytime
 
Hi, Andi.
Have you tried:
set a brakpoint to the invisible one
reset the brakpoint
compile
Click to expand...

Yes. It doesn't always work if there are multiple workspaces open, add-ins
running, and/or Access libraries referenced. In many cases, one or more of
the steps I suggested aren't necessary. One may not need to open the form
to ensure that any called library functions are running and additional
workspaces are open before resetting the breakpoint. Likewise, one may not
need to compact, close, and then reopen the application to remove all
instances of objects in libraries and add-ins to get a clean workspace.

However, taking all of the steps I suggested removes the ghost breakpoint
every time for all situations for all three versions of the VB Editor, no
matter what else is affecting the code.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
 
To fix it...
Click to expand...

Wow. Thanks Gunny! A client of mine called this morning with this
exact problem. Decompiling and recompiling and compacting seems to
have solved it but I'm bookmarking this suggestion!


John W. Vinson[MVP]
 
'69 Camaro said:
Hi, Bill.


Sounds like the debugger settings were saved the last time a break
point was set at that line of code. You can open and close the
database repeatedly, and the problem remains.

To fix it, open the database, then open the form in Form View. Press
<ALT><F11> to open the VB Editor. Click the "Reset" button on the
toolbar three times. (Answer to question I know you are going to
ask: Because sometimes twice just isn't enough.) Select the Debug
menu -> Compile <DatabaseName>, just in case the code wasn't already
compiled.

Press <ALT><Q> to return to Access. Select the Tools menu -> Database
Utilities -> Compact and Repair Database to compact the database.
When finished, close the database. Open the database again and open
the form in Form View, then enter text into the field that has
recently been causing the problem. The problem should be gone
because you've removed the ghost breakpoint.

And next time you are stepping through code, don't make any changes
to the code. That's what causes the ghost breakpoints.
Click to expand...

I haven't seen this cure before, but it sounds good. I've usually
solved the problem by opening the module in question in the VB Editor
and modifying the line "to itself", then recompiling, clearing all
breakpoints, and saving.

This is a keeper. Thanks, Gunny.
 
Hi, John.
Wow. Thanks Gunny!
Click to expand...

You're welcome!
A client of mine called this morning with this
exact problem.
Click to expand...

I didn't realize that this problem was that common. People look at me like
I have three heads when I mention it.
I'm bookmarking this suggestion!
Click to expand...

Wow! I'm honored! Thanks for the vote of confidence!

You probably already have this setting, but since you're bookmarking this,
Tom Wickerath reminded me that I forgot to mention that the "Compile On
Demand" VB Editor option should be turned off, too. It helps reduce the
number of occurrences of the ghost break point. (Thanks, Tom!)

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
 
Hi, Dirk.
This is a keeper.
Click to expand...

Wow! Another honor! Thanks! (Is lightning about to strike me?!!)
I haven't seen this cure before
Click to expand...

This is the fire hose approach, guaranteed to blast all ghost break points
from every dark corner.

You probably already have this setting, too, but Tom Wickerath reminded me
that I forgot to mention that the "Compile On Demand" VB Editor option
should be turned off. It helps reduce the number of occurrences of the
ghost break point. (Thanks, Tom!)
Thanks, Gunny.
Click to expand...

You're welcome!

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
 
'69 Camaro said:
You probably already have this setting, too, but Tom Wickerath
reminded me that I forgot to mention that the "Compile On Demand" VB
Editor option should be turned off. It helps reduce the number of
occurrences of the ghost break point. (Thanks, Tom!)
Click to expand...

I have that option set on, and I've never had what I'd consider a
problem with it -- I very rarely see ghost breakpoints. Maybe that's
because I don't normally edit code on the fly, and habitually compile
after code changes anyway.
 
Back
Top