Phantom debug break points in MS Access VBA code.

[Chrisso]

Hi All

I debugged a problem on a colleagues PC and used a break point on a
line of VBA code. I fixed the problem, removed the break point and
walked away happily.

Since then this colleague keeps reporting that VBA *stops* at this
"phantom" break point each time the code runs! The VBA editor comes up
with the line highlighted where I *had* the break point but it is no
longer marked - but the code still stops.

As you can imagine this is causing acute confusion and embarassment
for me.

Does anyone have experience of such a problem? How do I make sure that
the break points are cleared completely? I am desperate!

Thanks for any ideas,
Chrisso

 

[Ken Snell [MVP]]

This often happens when you edit code while the form or object is "running"
(a form is in Form view, for example, and you edit the code).

Open in design view the object that has the code module attached to it, and
go to that module (if it's a regular module, open that module in design
view).

Go to the procedure where the phantom breakpoint occurs.

In that procedure, copy the line on which the break occurs, and paste into
Notepad. Delete that line from the code; if it's an integral part of a
block, comment out the beginning/end of the block so that you don't have an
orphaned block. Save the object and close it. Compact/Repair the database.
Close your database.

Reopen the database. Open in design view the object that has the code module
attached to it, and go to that module (if it's a regular module, open that
module in design view). Put the code back to what it was originally. Save
the object and close it. Compact/Repair your database. Close your database.

The phantom breakpoint should be gone now.

 

[Daniel Summars]

Some corruption can cause this, and compact/repair alone may not resolve the problem.
Instead, decompile the program as follows (using full paths):

For MS-Access 2002:
"C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE" / DECOMPILE "C:\My MSAccess Program Folder\MyMSAccessProgram.mdb"

For MS-Access 2007:
"C:\Program Files\Microsoft Office\Office12\MSACCESS.EXE" / DECOMPILE "C:\My MSAccess Program Folder\MyMSAccessProgram.mdb"

Afterward, the program file will also probably be much smaller. The DECOMPILE will remove old code versions of code that is no longer needed, and possibly causing errors (such as ERROR # 49; Bad DLL calling convention; or MS-Access jumping into DEBUG mode for no known reason).

NOTE: The double quotes are necessary when there are embedded spaces in file/folder specificiations.



Chrisso wrote:

Phantom debug break points in MS Access VBA code.
11-Jun-09

Hi All

I debugged a problem on a colleagues PC and used a break point on a
line of VBA code. I fixed the problem, removed the break point and
walked away happily.

Since then this colleague keeps reporting that VBA *stops* at this
"phantom" break point each time the code runs! The VBA editor comes up
with the line highlighted where I *had* the break point but it is no
longer marked - but the code still stops.

As you can imagine this is causing acute confusion and embarassment
for me.

Does anyone have experience of such a problem? How do I make sure that
the break points are cleared completely? I am desperate!

Thanks for any ideas,
Chrisso

EggHeadCafe - Software Developer Portal of Choice
Run Remote ASP COM component from a SQL Batch job
http://www.eggheadcafe.com/tutorial...2-52fa2c2f3346/run-remote-asp-com-compon.aspx

 

[Daniel Summars]

Some corruption can cause this, and compact/repair alone may not resolve the problem.
Instead, decompile the program as follows (using full paths):

For MS-Access 2002:
"C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE" / DECOMPILE "C:\My MSAccess Program Folder\MyMSAccessProgram.mdb"

For MS-Access 2007:
"C:\Program Files\Microsoft Office\Office12\MSACCESS.EXE" / DECOMPILE "C:\My MSAccess Program Folder\MyMSAccessProgram.mdb"

Afterward, the program file will also probably be much smaller. The DECOMPILE will remove old code versions of code that is no longer needed, and possibly causing errors (such as ERROR # 49; Bad DLL calling convention; or MS-Access jumping into DEBUG mode for no known reason).

NOTE: The double quotes are necessary when there are embedded spaces in file/folder specificiations.



Chrisso wrote:

Phantom debug break points in MS Access VBA code.
11-Jun-09

Hi All

I debugged a problem on a colleagues PC and used a break point on a
line of VBA code. I fixed the problem, removed the break point and
walked away happily.

Since then this colleague keeps reporting that VBA *stops* at this
"phantom" break point each time the code runs! The VBA editor comes up
with the line highlighted where I *had* the break point but it is no
longer marked - but the code still stops.

As you can imagine this is causing acute confusion and embarassment
for me.

Does anyone have experience of such a problem? How do I make sure that
the break points are cleared completely? I am desperate!

Thanks for any ideas,
Chrisso

EggHeadCafe - Software Developer Portal of Choice
Top 10 .NET Framework Technologies to Learn in 2007
http://www.eggheadcafe.com/tutorial...44-469c1766614c/top-10-net-framework-tec.aspx