Forum Discussion
Phantom Breakpoints in MS Access VBA
Although it would be nice if Microsoft found time to correct this, the likelihood of that happening in the context of far more serious, work-stop type bugs, it's not likely to be addressed very soon.
That said, I think you can more or less reliably avoid this problem by making a preventative step one of the things you do just before distributing a new version of an accdb Front End to users.
This "phantom" seems to happen when you've been editing and saving VBA during a session, adding and removing break points. What can happen is that you do end up leaving behind one of those phantoms.
The remedial step I've adopted, based on experience and results shared by others, is that you simply insert and remove one blank line in a module. Then immediately Debug-->Compile your VBA. Then immediately Save it.
Run a Compact & Repair on the accdb. Test in run mode WITHOUT stopping the code anywhere. If the phantom break point does raise its ugly head again, go to the specific procedure and repeat the steps outlined above. At some point, you'll have eliminated them all.
Not as simple, I guess, as being able to count on some automatic process might be, it is effective.
Although it would be nice if Microsoft found time to correct this, the likelihood of that happening in the context of far more serious, work-stop type bugs, it's not likely to be addressed very soon.
That said, I think you can more or less reliably avoid this problem by making a preventative step one of the things you do just before distributing a new version of an accdb Front End to users.
This "phantom" seems to happen when you've been editing and saving VBA during a session, adding and removing break points. What can happen is that you do end up leaving behind one of those phantoms.
The remedial step I've adopted, based on experience and results shared by others, is that you simply insert and remove one blank line in a module. Then immediately Debug-->Compile your VBA. Then immediately Save it.
Run a Compact & Repair on the accdb. Test in run mode WITHOUT stopping the code anywhere. If the phantom break point does raise its ugly head again, go to the specific procedure and repeat the steps outlined above. At some point, you'll have eliminated them all.
Not as simple, I guess, as being able to count on some automatic process might be, it is effective.
C&R also clears the issue for me, and you should always run this as one of the last steps before publishing a revision.
If C&R shouldn't work for you, a decompile will. Make a backup and then run:
MSACCESS.EXE yourdb.accdb /decompile
Then call C&R, close Access, relaunch the application, call Compile, and save the modules.