Phantom Breakpoints in MS Access VBA

%3CLINGO-SUB%20id%3D%22lingo-sub-1907299%22%20slang%3D%22en-US%22%3EPhantom%20Breakpoints%20in%20MS%20Access%20VBA%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1907299%22%20slang%3D%22en-US%22%3E%3CP%3EI've%20been%20using%20Access%20for%20better%20than%2020%20years%20at%20this%20point.%26nbsp%3B%20Only%20in%20the%20last%20few%20versions%20have%20I%20noticed%20this%20problem%20of%20%22Phantom%20breakpoints.%22%26nbsp%3B%20This%20is%20where%20you'll%20be%20working%20on%20a%20module%2C%20or%20piece%20of%20VBA%20code%20behind%20a%20button%2C%20form%2C%20label%2C%20or%20other%20object%2C%20and%20you%20click%20the%20breakpoint%20little%20maroon%20circle%20out%20to%20the%20left%20of%20your%20code%2C%20and%20when%20you%20run%20the%20code%20it%20stops%20at%20that%20breakpoint.%26nbsp%3B%20It%20works%20great!%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3EThe%20problem%20comes%20however%20when%20you%20try%20to%20un-check%20the%20maroon%20breakpoint%20-%20either%20by%20clicking%20it%20and%20it%20goes%20away%2C%20or%20by%20using%20the%20menu%20option%20%22clear%20all%20breakpoints%22%20-%20and%20then%20most%20of%20time%20time%20breakpoint%20will%20cease%20to%20stop%20the%20flow%20of%20the%20code.%26nbsp%3B%20Unfortunately%20it%20doesn't%20always%20go%20away.%26nbsp%3B%20Maybe%202%20out%20of%2010%20times%20it%20will%20not%20really%20clear%20the%20breakpoint%2C%20and%20typically%20I%20don't%20find%20out%20about%20it%20until%20it's%20been%20distributed%20to%20the%20clients%20and%20I%20get%20a%20call%20that%20%22Your%20application%20has%20stopped%20on%20that%20stupid%20yellow%20code%20thing%20again!%22%26nbsp%3B%20If%20it%20only%20happened%201%20out%20of%20100%20times%2C%20that%20would%20be%20something%20I%20could%20live%20with%2C%20but%2020%25%20of%20the%20time%20is%20move%20than%20I%20can%20bear.%26nbsp%3B%20Can%20someone%20people%20tell%20me%20of%20a%20cure%20for%20this%20problem%3F%26nbsp%3B%20Is%20it%20something%20Microsoft%20is%20aware%20of%3F%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMicrosoft%20makes%20changes%20to%20the%20interface%20that%20involve%20the%20look%20of%20buttons%2C%20or%20the%20alternate%20row%20color%20setting%20on%20reports%2C%20which%20are%20nice%20I%20guess%20-%20I%20prefer%20the%20plain%20jane%20look%20of%20forms%20and%20reports%2C%20however%20You%20would%20think%20they%20would%20fix%20this%20bug%20before%20devoting%20time%20to%20making%20more%20%22flash%22%20for%20the%20interface.%3CBR%20%2F%3E%3CBR%20%2F%3E-Breakpointed%20in%20Tampa%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1907299%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3E2013%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3E2016%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EAccess%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EDeveloper%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1917639%22%20slang%3D%22en-US%22%3ERe%3A%20Phantom%20Breakpoints%20in%20MS%20Access%20VBA%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1917639%22%20slang%3D%22en-US%22%3EYes%2C%20this%20is%20a%20known%20issue%20and%20had%20been%20brought%20to%20their%20attention%20in%20the%20past.%20There%20are%20numerous%20issues%20with%20each%20newer%20version%20of%20Access%2C%20just%20one%20more%20reason%20to%20stay%20with%20the%20tried%2C%20tested%20and%20true%20older%20versions!!%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1920883%22%20slang%3D%22en-US%22%3ERe%3A%20Phantom%20Breakpoints%20in%20MS%20Access%20VBA%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1920883%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F874884%22%20target%3D%22_blank%22%3E%40BrianDP222%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAlthough%20it%20would%20be%20nice%20if%20Microsoft%20found%20time%20to%20correct%20this%2C%20the%20likelihood%20of%20that%20happening%20in%20the%20context%20of%20far%20more%20serious%2C%20work-stop%20type%20bugs%2C%20it's%20not%20likely%20to%20be%20addressed%20very%20soon.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThat%20said%2C%20I%20think%20you%20can%20more%20or%20less%20reliably%20avoid%20this%20problem%20by%20making%20a%20preventative%20step%20one%20of%20the%20things%20you%20do%20just%20before%20distributing%20a%20new%20version%20of%20an%20accdb%20Front%20End%20to%20users.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20%22phantom%22%20seems%20to%20happen%20when%20you've%20been%20editing%20and%20saving%20VBA%20during%20a%20session%2C%20adding%20and%20removing%20break%20points.%20What%20can%20happen%20is%20that%20you%20do%20end%20up%20leaving%20behind%20one%20of%20those%20phantoms.%3C%2FP%3E%3CP%3EThe%20remedial%20step%20I've%20adopted%2C%20based%20on%20experience%20and%20results%20shared%20by%20others%2C%20is%20that%20you%20simply%20insert%20and%20remove%20one%20blank%20line%20in%20a%20module.%20Then%20immediately%20Debug--%26gt%3BCompile%20your%20VBA.%20Then%20immediately%20Save%20it.%3C%2FP%3E%3CP%3ERun%20a%20Compact%20%26amp%3B%20Repair%20on%20the%20accdb.%20Test%20in%20run%20mode%20WITHOUT%20stopping%20the%20code%20anywhere.%20If%20the%20phantom%20break%20point%20does%20raise%20its%20ugly%20head%20again%2C%20go%20to%20the%20specific%20procedure%20and%20repeat%20the%20steps%20outlined%20above.%20At%20some%20point%2C%20you'll%20have%20eliminated%20them%20all.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENot%20as%20simple%2C%20I%20guess%2C%20as%20being%20able%20to%20count%20on%20some%20automatic%20process%20might%20be%2C%20it%20is%20effective.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Occasional Visitor

I've been using Access for better than 20 years at this point.  Only in the last few versions have I noticed this problem of "Phantom breakpoints."  This is where you'll be working on a module, or piece of VBA code behind a button, form, label, or other object, and you click the breakpoint little maroon circle out to the left of your code, and when you run the code it stops at that breakpoint.  It works great! 

The problem comes however when you try to un-check the maroon breakpoint - either by clicking it and it goes away, or by using the menu option "clear all breakpoints" - and then most of time time breakpoint will cease to stop the flow of the code.  Unfortunately it doesn't always go away.  Maybe 2 out of 10 times it will not really clear the breakpoint, and typically I don't find out about it until it's been distributed to the clients and I get a call that "Your application has stopped on that stupid yellow code thing again!"  If it only happened 1 out of 100 times, that would be something I could live with, but 20% of the time is move than I can bear.  Can someone people tell me of a cure for this problem?  Is it something Microsoft is aware of? 

 

Microsoft makes changes to the interface that involve the look of buttons, or the alternate row color setting on reports, which are nice I guess - I prefer the plain jane look of forms and reports, however You would think they would fix this bug before devoting time to making more "flash" for the interface.

-Breakpointed in Tampa

 

4 Replies

Yes, this is a known issue and had been brought to their attention in the past. There are numerous issues with each newer version of Access, just one more reason to stay with the tried, tested and true older versions!!

 

Feel free to send Microsoft your comments through the Feedback command in Access and also through access.uservoice.com

@BrianDP222 

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.

Usually after a significant update, a customer emails a screen shot of the yellow highlighted code and asks "What do I do now". This problem is very random. But my solution has been to simply comment out the offending line of code, insert a blank line, and retype the exact same code on the new line. The phantom breakpoint is essentially disabled by the comment mark. Feel free to use my solution without any attributions to my genius intellect. :)

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.