I've made a change to an app that's been running for years. After adding
some code, now the debugger breaks in at a particular line even though I have
no breakpoint set there - I've Cleared All Breakpoints from the Debug menu.
If I click continue, the app continues without error. I need this code to
keep running - the users will not know what to do and shouldn't have to deal
with it anyway. Any ideas?

VBE sometimes remembers "phantom" breakpoints.

Two ways that I use to fix this problem.

(1) Comment out the line on which the breakpoint occurs. If the code won't
compile without that line, then comment out a block of code so that the code
can compile without it. Compile the code. Close the database. Open the
database. Uncomment out the code. Compile the code.

(2) Use the undocumented decompile switch when opening the database so that
all compiled code is uncompiled.
"PathToAccessExecutable\msaccess.exe" /decompile
"PathToYourDataBaseFile\DatabaseFileName.mdb"


--

Ken Snell
<MS ACCESS MVP>


"DJ Becker" <DJ (E-Mail Removed)> wrote in message
newsA0E9301-0716-4E1E-86C3-(E-Mail Removed)...
> I've made a change to an app that's been running for years. After adding
> some code, now the debugger breaks in at a particular line even though I
> have
> no breakpoint set there - I've Cleared All Breakpoints from the Debug
> menu.
> If I click continue, the app continues without error. I need this code to
> keep running - the users will not know what to do and shouldn't have to
> deal
> with it anyway. Any ideas?

Beautiful - worked like a charm - Thanks.

I guess my frustration was inhibiting my ability to think of a simple
solution like that - I guess I expect a debugger to HELP me rather than get
in the way. Silly me.

This is my first post here and I have to say the answer appeared LOTS
quicker than it ever would have from searching the knowledge base. I imagine
I'll be back.

Thanks again.

-- Don --

"Ken Snell [MVP]" wrote:

> VBE sometimes remembers "phantom" breakpoints.
>
> Two ways that I use to fix this problem.
>
> (1) Comment out the line on which the breakpoint occurs. If the code won't
> compile without that line, then comment out a block of code so that the code
> can compile without it. Compile the code. Close the database. Open the
> database. Uncomment out the code. Compile the code.
>
> (2) Use the undocumented decompile switch when opening the database so that
> all compiled code is uncompiled.
> "PathToAccessExecutable\msaccess.exe" /decompile
> "PathToYourDataBaseFile\DatabaseFileName.mdb"
>
>
> --
>
> Ken Snell
> <MS ACCESS MVP>
>
>
> "DJ Becker" <DJ (E-Mail Removed)> wrote in message
> newsA0E9301-0716-4E1E-86C3-(E-Mail Removed)...
> > I've made a change to an app that's been running for years. After adding
> > some code, now the debugger breaks in at a particular line even though I
> > have
> > no breakpoint set there - I've Cleared All Breakpoints from the Debug
> > menu.
> > If I click continue, the app continues without error. I need this code to
> > keep running - the users will not know what to do and shouldn't have to
> > deal
> > with it anyway. Any ideas?
>
>
>

"DJ Becker" <DJ (E-Mail Removed)> wrote in message
newsA0E9301-0716-4E1E-86C3-(E-Mail Removed)...

> I've made a change to an app that's been running for years. After adding
> some code, now the debugger breaks in at a particular line even though I have
> no breakpoint set there - I've Cleared All Breakpoints from the Debug menu.
> If I click continue, the app continues without error. I need this code to
> keep running - the users will not know what to do and shouldn't have to deal
> with it anyway. Any ideas?

Here is a past post by Gunny on this issue:
>>>>>

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.
>>>>>

Good luck,
--
Jeff Conrad
Access Junkie
Bend, Oregon

You're welcome.

--

Ken Snell
<MS ACCESS MVP>

"DJ Becker" <DJ (E-Mail Removed)> wrote in message
news:829A5C64-05E0-4EED-9FE3-(E-Mail Removed)...
> Beautiful - worked like a charm - Thanks.
>
> I guess my frustration was inhibiting my ability to think of a simple
> solution like that - I guess I expect a debugger to HELP me rather than
> get
> in the way. Silly me.
>
> This is my first post here and I have to say the answer appeared LOTS
> quicker than it ever would have from searching the knowledge base. I
> imagine
> I'll be back.
>
> Thanks again.
>
> -- Don --
>
> "Ken Snell [MVP]" wrote:
>
>> VBE sometimes remembers "phantom" breakpoints.
>>
>> Two ways that I use to fix this problem.
>>
>> (1) Comment out the line on which the breakpoint occurs. If the code
>> won't
>> compile without that line, then comment out a block of code so that the
>> code
>> can compile without it. Compile the code. Close the database. Open the
>> database. Uncomment out the code. Compile the code.
>>
>> (2) Use the undocumented decompile switch when opening the database so
>> that
>> all compiled code is uncompiled.
>> "PathToAccessExecutable\msaccess.exe" /decompile
>> "PathToYourDataBaseFile\DatabaseFileName.mdb"
>>
>>
>> --
>>
>> Ken Snell
>> <MS ACCESS MVP>
>>
>>
>> "DJ Becker" <DJ (E-Mail Removed)> wrote in message
>> newsA0E9301-0716-4E1E-86C3-(E-Mail Removed)...
>> > I've made a change to an app that's been running for years. After
>> > adding
>> > some code, now the debugger breaks in at a particular line even though
>> > I
>> > have
>> > no breakpoint set there - I've Cleared All Breakpoints from the Debug
>> > menu.
>> > If I click continue, the app continues without error. I need this code
>> > to
>> > keep running - the users will not know what to do and shouldn't have to
>> > deal
>> > with it anyway. Any ideas?
>>
>>
>>

"David C. Holley" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)
> Q: When I click the RESET button three times, is there anything
> special I need to say like "I wish I were home", "Bill Gates is god",
> "Please, oh baby, please work for daddy"

No, but you do have to put $5 in an envelope and send it to Gunny's Home
for Wayward Programmers.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

"Dirk Goldgar" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> No, but you do have to put $5 in an envelope and send it to Gunny's Home
> for Wayward Programmers.

Is that tax deductible?
I could use a few more deductions.

--
Jeff Conrad
Access Junkie
Bend, Oregon

"Jeff Conrad" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)
> "Dirk Goldgar" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>> No, but you do have to put $5 in an envelope and send it to Gunny's
>> Home for Wayward Programmers.
>
> Is that tax deductible?
> I could use a few more deductions.

That's between you and the IRS. Don't let me stand in your way.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

2 years later, and this post just helped me resolve a problem that cropped up
today with an Access database somebody else wrote. Your post has withstood
the test of time.

Thanks!

"Ken Snell [MVP]" wrote:

> VBE sometimes remembers "phantom" breakpoints.
>
> Two ways that I use to fix this problem.
>
> (1) Comment out the line on which the breakpoint occurs. If the code won't
> compile without that line, then comment out a block of code so that the code
> can compile without it. Compile the code. Close the database. Open the
> database. Uncomment out the code. Compile the code.
>
> (2) Use the undocumented decompile switch when opening the database so that
> all compiled code is uncompiled.
> "PathToAccessExecutable\msaccess.exe" /decompile
> "PathToYourDataBaseFile\DatabaseFileName.mdb"
>
>
> --
>
> Ken Snell
> <MS ACCESS MVP>
>
>
> "DJ Becker" <DJ (E-Mail Removed)> wrote in message
> newsA0E9301-0716-4E1E-86C3-(E-Mail Removed)...
> > I've made a change to an app that's been running for years. After adding
> > some code, now the debugger breaks in at a particular line even though I
> > have
> > no breakpoint set there - I've Cleared All Breakpoints from the Debug
> > menu.
> > If I click continue, the app continues without error. I need this code to
> > keep running - the users will not know what to do and shouldn't have to
> > deal
> > with it anyway. Any ideas?
>
>
>

Another common method is to set and clear a breakpoint on the line that has
the phantom breakpoint. I've had fairly good luck with that method so far,
and it's nice and quick.


Rob

JDRaven wrote:
> 2 years later, and this post just helped me resolve a problem that cropped up
> today with an Access database somebody else wrote. Your post has withstood
> the test of time.
>
> Thanks!
>
> "Ken Snell [MVP]" wrote:
>
>> VBE sometimes remembers "phantom" breakpoints.
>>
>> Two ways that I use to fix this problem.
>>
>> (1) Comment out the line on which the breakpoint occurs. If the code won't
>> compile without that line, then comment out a block of code so that the code
>> can compile without it. Compile the code. Close the database. Open the
>> database. Uncomment out the code. Compile the code.
>>
>> (2) Use the undocumented decompile switch when opening the database so that
>> all compiled code is uncompiled.
>> "PathToAccessExecutable\msaccess.exe" /decompile
>> "PathToYourDataBaseFile\DatabaseFileName.mdb"
>>
>>
>> --
>>
>> Ken Snell
>> <MS ACCESS MVP>
>>
>>
>> "DJ Becker" <DJ (E-Mail Removed)> wrote in message
>> newsA0E9301-0716-4E1E-86C3-(E-Mail Removed)...
>>> I've made a change to an app that's been running for years. After adding
>>> some code, now the debugger breaks in at a particular line even though I
>>> have
>>> no breakpoint set there - I've Cleared All Breakpoints from the Debug
>>> menu.
>>> If I click continue, the app continues without error. I need this code to
>>> keep running - the users will not know what to do and shouldn't have to
>>> deal
>>> with it anyway. Any ideas?
>>
>>