I have a complex MS Access 2013 database with tens of forms. On one of the forms, I have button with vba procedure back to it, which returns values from MS SQL(ADODB) and puts them into the textboxes.
Problem is, whenever i click this button, it steps into compile menu as if there was a breakpoint, but in fact there is no breakpoint. Of course there are no errors / MsgBoxes and If I just click F5 or F8, it goes well.
Has anyone the Idea, what may be wrong?
Phantom Breakpoints can usually be fixed by copying the line which stops the code execution into notepad. Then delete the line from the VBEditor and insert it again from the notepad.
If this doesn't work, try decompiling the database:
Open cmd and enter the following:
<full path to your database> /decompile
example:
C:\testDB.accdb /decompile
In fact you can just re-paste it from the clipboard, you don't need to use notepad. But don't paste it back into the same line. Delete the bad line.
Phantom Breakpoints don't go away with a restart.
This issue has been around for years and yet MS won't address it. Annoying!
Phantom Breakpoint strikes again :(
This showed up in such a strange way that I feel compelled to post it somewhere. This seems like the most obvious place, but I'm glad to move these comments elsewhere as appropriate.
I have an Access 2010 ACCDE giving me this same error: "Requested type library or wizard is not a VBA project" when I click a button on the main navigation form. I try an earlier version with same references and exactly the same code (in the nav form and other areas relating to the button) and it works fine. However, when I open the ACCDB used to build the "bad" ACCDE, and click the same button, I get a different error: Error 16 - "Expression too complex".
I fixed the issue by commenting out the associated VBA lines in the nav form and duplicating the uncommented code below the original lines.
The strangest part was that it wasn't until after several debugging sessions that it started behaving as the original posting above, where the it would break to the invisible breakpoint. It displayed the misleading errors above before that.
My standard practice now is to use Clear All Breakpoints (under Debug menu) after all development sessions. Hopefully that will prevent this in the future.
