I have this problem that really upsets my users. We are using Access
2007. The Access program was written in Access 2003 with an mdb
extension. The tables are in a second linked Access 2003 file with
the extension mdb. The two programs are in the same folder on the C:
drive. The program has about 20,000 lines of VBA code. I inherited
this program, but I have made numerous improvements to it.

The problem is that for no apparent reason, when using the program it
goes into the VB editor and stops. I tell the users to press F5. It
then continues to the end. There seems to be no error in the code. It
stops usually at the function or sub statement in the procedures.
there is no error message.

Does anyone know how I can stop this from happening or what causes it?

Bob wrote:

You might want to do a search for
DoCmd.OpenModule

Is it typically the same module? If so, seach for the module name if
the above doesn't help. Maybe the original code use using something
during debugging.

On 8/17/10 9:21 AM, Bob wrote:
Are you saying it behaves as if a breakpoint was set but there's no
breakpoint? If that is the case, it's easy to fix the phantom
breakpoint: On the offending line, cut out the line then delete that
line and paste it back in. Compile the code. That phantom breakpoint
will then disappear. It's also probably necessary to re-distribute the
file to your users so they don't have that problems anymore.

It can happen whenever one leaves the breakpoint but didn't clear it out
- though VBE is supposed to be able to automatically clean up all
breakpoints at say, shutdown, it always doesn't happen and thus the
phantom breakpoint.

HTH.

Banana <Banana (AT) Republic (DOT) com> wrote in
news:4C6AE877.7030200 (AT) Republic (DOT) com:

I had this happen recently, and did a decompile/recompile, then
cleared all breakpoints and saved the project, and that took care of
it. I didn't have to delete the line of code.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

On 8/17/10 2:26 PM, David W. Fenton wrote:
Well, deleting the line and re-pasting it back is sufficient (at least
it was for me) to do away with the phantom breakpoint and more
importantly, that does not require doing a decompile. As Michael Kaplan
has stated on his website, one should not use decompile as knee-jerk
reaction but rather as a last resort. Besides it's much quicker that way.

Banana <Banana (AT) Republic (DOT) com> wrote in
news:4C6B0D08.3030505 (AT) Republic (DOT) com:

Well, to me, a phantom breakpoint indicates that there's a
discrepancy between the canonical code I see onscreen and the
compiled p-code (I'm assuming break points get stored somewhere in
the p-code or in between the canonical code and the p-code), so this
seems like exactly the type of problem decompile was designed to
fix.

I also think MichKa was way too cautious in his advice about
decompile, but I understand why, since most people needing it are
using bad coding practices that can make decompile dangerous (as in,
it will cause you to lose code that would otherwise remain intact if
you didn't decompile). Since I practice good coding practices, I
feel no danger in decompiling (and, of course, you should always
back up before a decompile).

The reason I don't think a change to the canonical code is
necessarily going to fix the phantom breakpoint without a decompile
is because while it would seem that any pointers to a particular
line would be lost if that line is deleted, I can't see there's any
guarantee that it would be. I mean, you're in a state where things
are not working the way they are supposed to, so assuming that
removing a line will actually fix the erroneous pointer seems
ill-advised. Discarding all the p-code and returning to the
canonical code by itself seems to me to be the most reliable way to
fix the problem.

And, contra MichKa, decompile is perfectly safe, particularly if you
back up your file beforehand. And if you lose code decompiling
because of a phantom breakpoint, that means your VBA project had
huge problems already, and the phantom breakpoint might very well
have been the canary in the coalmine. Not doing a decompile may mean
that you end up with much worse problems later on.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

On Aug 17, 12:52*pm, Banana <Ban... (AT) Republic (DOT) com> wrote:

HTH,
Thanks. That is the problem. I use a lot of breaks when I back
engineer the VBA code in the applications. So I will be careful to
delete the breaks before I close. Also, the cut and re-paste works
well.

Most of my users are microbiologists. The program keeps track of all
the assays they do on the MSL spacecraft before it will be launched to
Mars in December 2011. Already it includes 20,000 petri dishes whose
colonies have been recorded. It generates barcodes for the petri
dishes. Then these are scanned and the colony counts typed in. I
have written another Excess program that does all of the statistical
analysis of the data for the report prior to launch. It's all fun! I
have grown into an avid fan of Access.

On Aug 17, 2:26*pm, "David W. Fenton" <NoEm... (AT) SeeSignature (DOT) invalid>
wrote:
Bana, see my reply to HTH above.
Thanks.

On 8/19/10 12:26 PM, Bob wrote:
Glad that fixed the issue.

Two more things that may be helpful:

1) I recalled just now that one easy way to create a phantom breakpoint
is to run the code with breakpoint set, then at runtime, edit the code
and continue. That kinds of screws up the project's state and for that
reason several developers prefer to avoid doing any editing of VBA when
in break mode. Similarly, they may choose to clear the "Compile on
Demand" checkbox which is checked by default.

2) David mentioned doing a decompile - Though I prefer to do it sparsely
as possible, doing a decompile before distributing a version, especially
when there has been major changes, seems to me a good idea to ensure
you've cleaned out all gunk left behind during the development. Even
better yet, consider distributing MDE even if you aren't concerned about
protecting your VBA code simply as a means to guarantee that your VBA
code doesn't get changed by accident by honest users and avoid other issues.

Finally -- HTH = "Hope that helped"

Best of luck!