2nd try.

My code keeps on breaking into the debugger in spite of the fact that
I have the option "Break on Unhandled Errors" ticked and I have error
handlers built in.

I have tried everything suggested by Ken Snell and Jeff Conrad in an
earlier thread on this subject and it's still breaking.

I'm pulling my hair out here.

I'm using Access XP SP3 in Access 2000 format on a Win2K Pro SP4
machine.

Thanks for any help.

RD

> I have tried everything suggested by Ken Snell and Jeff Conrad in an
> earlier thread on this subject and it's still breaking.

Which thread? Which suggestions?

(david)

"RD" <(E-Mail Removed)> wrote in message
news:1109868852.3cfbffcb54ecc5d640cab455b4168b8c@teranews...
> 2nd try.
>
> My code keeps on breaking into the debugger in spite of the fact that
> I have the option "Break on Unhandled Errors" ticked and I have error
> handlers built in.
>
> I have tried everything suggested by Ken Snell and Jeff Conrad in an
> earlier thread on this subject and it's still breaking.
>
> I'm pulling my hair out here.
>
> I'm using Access XP SP3 in Access 2000 format on a Win2K Pro SP4
> machine.
>
> Thanks for any help.
>
> RD
>

On Fri, 4 Mar 2005 16:29:41 +1100, "david epsom dot com dot au"
<david@epsomdotcomdotau> wrote:

>> I have tried everything suggested by Ken Snell and Jeff Conrad in an
>> earlier thread on this subject and it's still breaking.
>
>Which thread? Which suggestions?
>
>(david)
>

Thread-Topic: Access xp - Why does debugger break in when I have no
breakpoint .

Suggestions:
Ken Snell:
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"

Jeff Conrad:
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.

Is your code stopping at an error? Or is it stopping at
a break point?

(david)

"RD" <(E-Mail Removed)> wrote in message
news:1109962603.d367b3a9ba2b85f074d112ef4d5eae76@teranews...
> On Fri, 4 Mar 2005 16:29:41 +1100, "david epsom dot com dot au"
> <david@epsomdotcomdotau> wrote:
>
>>> I have tried everything suggested by Ken Snell and Jeff Conrad in an
>>> earlier thread on this subject and it's still breaking.
>>
>>Which thread? Which suggestions?
>>
>>(david)
>>
>
> Thread-Topic: Access xp - Why does debugger break in when I have no
> breakpoint .
>
> Suggestions:
> Ken Snell:
> 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"
>
> Jeff Conrad:
> 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.

At an error. I've cleared the breakpoints. I've done all that stuff
below. I'm going nuts, here.



On Mon, 7 Mar 2005 10:14:10 +1100, "david epsom dot com dot au"
<david@epsomdotcomdotau> wrote:

>Is your code stopping at an error? Or is it stopping at
>a break point?
>
>(david)
>
>"RD" <(E-Mail Removed)> wrote in message
>news:1109962603.d367b3a9ba2b85f074d112ef4d5eae76@teranews...
>> On Fri, 4 Mar 2005 16:29:41 +1100, "david epsom dot com dot au"
>> <david@epsomdotcomdotau> wrote:
>>
>>>> I have tried everything suggested by Ken Snell and Jeff Conrad in an
>>>> earlier thread on this subject and it's still breaking.
>>>
>>>Which thread? Which suggestions?
>>>
>>>(david)
>>>
>>
>> Thread-Topic: Access xp - Why does debugger break in when I have no
>> breakpoint .
>>
>> Suggestions:
>> Ken Snell:
>> 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"
>>
>> Jeff Conrad:
>> 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.
>

> At an error.

What is the error?

(david)

"RD" <(E-Mail Removed)> wrote in message
news:1110212871.69f895a2357ccc38692f191f6148eddd@teranews...
> At an error. I've cleared the breakpoints. I've done all that stuff
> below. I'm going nuts, here.
>
>
>
> On Mon, 7 Mar 2005 10:14:10 +1100, "david epsom dot com dot au"
> <david@epsomdotcomdotau> wrote:
>
>>Is your code stopping at an error? Or is it stopping at
>>a break point?
>>
>>(david)
>>
>>"RD" <(E-Mail Removed)> wrote in message
>>news:1109962603.d367b3a9ba2b85f074d112ef4d5eae76@teranews...
>>> On Fri, 4 Mar 2005 16:29:41 +1100, "david epsom dot com dot au"
>>> <david@epsomdotcomdotau> wrote:
>>>
>>>>> I have tried everything suggested by Ken Snell and Jeff Conrad in an
>>>>> earlier thread on this subject and it's still breaking.
>>>>
>>>>Which thread? Which suggestions?
>>>>
>>>>(david)
>>>>
>>>
>>> Thread-Topic: Access xp - Why does debugger break in when I have no
>>> breakpoint .
>>>
>>> Suggestions:
>>> Ken Snell:
>>> 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"
>>>
>>> Jeff Conrad:
>>> 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.
>>
>

"RD" <(E-Mail Removed)> wrote in message
news:1110212871.69f895a2357ccc38692f191f6148eddd@teranews
> At an error. I've cleared the breakpoints. I've done all that stuff
> below. I'm going nuts, here.

I believe I've found some sanity for you. See your other thread in this
newsgroup.

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

(please reply to the newsgroup)