MS Access unwanted BreakPoint

Question

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?

Clingfish

Could you please give as the vba code where the problem appears? – Lenhard

Answer 1

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

Yetac

Sometimes even a restart in Access can fix it actually. – Lenhard

@gizlmeier, Thank you. simply copying line to pad, deleting from VBE and then putting it back helped me. – Clingfish

even faster: delete a whitespace, save, compile, watch how phantom breakpoint is gone be happy – Begird

Answer 2

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!

Wheezy

Answer 3

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.

Churchy

I thought the Clear All Breakpoints was a useful suggestion for this issue, but whatever. Hopefully others having this combination of errors will find this answer useful. – Churchy

Also, if anyone can point me to a post that associates either of these error messages with the phantom breakpoint issue, I will happily vote up those and remove this post. I am a new poster and am just trying to help others. – Churchy

Answer 4

The phantom breakpoint thing has been an issue for a couple of versions from what I remember. Between that, and the new thing where the code window activates just by floating over it- even if you don't click in that window- I'm not sure I can endure anymore "Improvements". Hell the the program ran pretty damned good about 3 versions ago! Honestly the new "fluff" they've added - alternate colors on report lines-or other data in tables- I don't use any of that and spend more time taking off alternative line colors when I don't want it!

Fix more bugs and spend less time on new features!!!

Delila

Answer 5

Ghost breakpoint within referenced accdb code library! Had a very similar problem. While starting the application it stops highlighting a line in yellow. Unfortunately the highlighted line was in a referenced accdb library for additional code which I share between different databases. The other databases still worked fine with the identical part of code. Deleting the ghost breakpoint line didn't help (references are read only anyway), so, the source of the problem should be within the code of the calling database and not where the call runs into a ghost breakpoint. Toggle the reference then, of course with save and restart, stopped the ghost breakpoint. Just in case there is somebody with the same problem connected to referenced code.

Kaolinite