Removed(!) breakpoints are re-appearing in production

[RTL]

Hello all,

Lately, we've been experiencing an interesting "situation." In the code, we
set a break point at where to stop. Then we remove the break points, save
changes (if they already aren't saved) and copy the file to the workstations
for the users.

Now, when the user uses the DB, the code will halt where the original (and
removed) break point existed. There is no break point set, but if you hit
F5, the code resumes execution.

The workaround for this is to copy the line of code that it breaks at, and
paste it to the line below. Then to comment (Remark) out the original line.
Then it works without breaking. :|

This happens all the time lately--regardless of whether it is closed then
re-opened...

Has anyone else experienced this?

Cheers,

Rich
www.techarts.com

 

[Tom Wickerath]

Hi Rich,

I have experienced this situation myself every once in a while, but certainly not all the time.
When the code breaks on a "phantom" break point, I can press F5 to get things moving again, and
then (on my PC) it doesn't tend to happen again. Here are a couple of things to try:

1). In the VBE editor, click on Tools > Options. Clear the option that reads Compile on Demand
if it is checked (default is checked).

2). Make sure you do periodic Compact and Repairs of your database (Tools > Database Utilities...

Compact and repair)

3). Make sure you have all the latest service packs installed for your operating system and for
your version of Office.

4). If the problem still persists, make a copy of your database. Then start Access with the
decompile switch. You can use the following:

Start > Run enter: "msaccess /decompile" (without the quotes)

The next database you open will get it's compiled P-code discarded upon opening. Do a compact
and repair right away. Then open the VBE editor and click on Debug > Compile. Entering the
command in the Run dialog will work as long as you don't have multiple versions of Access
installed, since this command will start the copy of msaccess.exe that is found in the path. If
you have multiple versions of Access (for instance, Access 97 and Access 2002), then you can
create a shortcut that points to the correct copy of msaccess.exe in the target line, and
includes the /decompile switch.

For more information on this option, read this:

The real deal on the /Decompile switch
http://www.trigeminal.com/usenet/usenet004.asp?1033


Tom
________________________________________


Hello all,

Lately, we've been experiencing an interesting "situation." In the code, we
set a break point at where to stop. Then we remove the break points, save
changes (if they already aren't saved) and copy the file to the workstations
for the users.

Now, when the user uses the DB, the code will halt where the original (and
removed) break point existed. There is no break point set, but if you hit
F5, the code resumes execution.

The workaround for this is to copy the line of code that it breaks at, and
paste it to the line below. Then to comment (Remark) out the original line.
Then it works without breaking. :|

This happens all the time lately--regardless of whether it is closed then
re-opened...

Has anyone else experienced this?

Cheers,

Rich
www.techarts.com

 

[Lynn Trapp]

Have you compiled the database?

 

[RTL]

Hi Tom and Lynn,

Thank you both very much for responding. Yes, we have recompiled it
repeatedly. I am going to run with what Tom wrote and see if that helps!

Thanks again, I'll post the results!

Cheers,

Rich

PS: Thanks again!

 

[Albert D. Kallal]

I would as a rule ALWAYS distribute a mde file to each user....

 

[david epsom dot com dot au]

I've found that I am likely to get this common problem if I CLOSE
the database before REMOVING the break points. The IDE pointers
are removed from the source code, but the break points stay in the
compiled code.

(david)

 

[Tom Wickerath]

Yesterday evening (it's 2:22 AM right now!), I attended the Access SIG group meeting on the
Microsoft campus in Redmond. During the technical Q&A portion of the meeting, I asked about code
breaking where a break point was previously removed. Tim Getsch, a Microsoft Access Program
Manager, answered that he too has seen this happen. He said that he believed you can prevent the
problem by:

1) Remove all break points
2) Make some change in the code (for example enter a blank line with the return key, or remove an
extra blank line)
3) Compile the code (Debug > Compile)

The act of compiling the code will toss away all previously compiled P-Code (in Access 2000 and
later). Tim felt that my fourth recommendation, using the /decompile switch, would work too
since this gets rid of previously compiled P-Code. So, I guess the answer is to make sure to
change something in the code (press the space bar in a commented line, for example), and then do
a Debug > Compile.


Also a friend of mine included the following comments in a reply on this subject:
______________________________
"I had the phantom break point on several occasions while using Access 2K, but it's fairly common
now that I'm working in Access '03"

and

"What works for me is clicking on the "Reset" toolbar button in the VB Editor a few times.
Sometimes one click isn't enough, so I click it a second time -- and then a third time just to
make sure!"
______________________________

Tom

_________________________________________

Hi Tom and Lynn,

Thank you both very much for responding. Yes, we have recompiled it
repeatedly. I am going to run with what Tom wrote and see if that helps!

Thanks again, I'll post the results!

Cheers,

Rich

PS: Thanks again!

_________________________________________

 

[Lynn Trapp]

Tom,
The one time I saw that happen, I solved it by simply compiling the code.

 

[Tom Wickerath]

Hi Lynn,

Yes, this is in line with Tim's comments. When you compile the code, you are automatically
tossing the previously compiled P-Code, and replacing it with a fresh copy. Makes sense to me.

Tom
___________________________________

Tom,
The one time I saw that happen, I solved it by simply compiling the code.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm


___________________________________

 

[Lynn Trapp]

It makes perfect sense to me too, so I'm wondering why it didn't help RTL.
Perhaps he didn't remove all breakpoints before the compile???

 

[Dirk Goldgar]

It makes perfect sense to me too, so I'm wondering why it didn't help
RTL. Perhaps he didn't remove all breakpoints before the compile???

Then of course there's the fact that you have to have modified the
source code in some way since the last time it was compiled, or you
won't even get the Compile menu option.

 

[Lynn Trapp]

Then of course there's the fact that you have to have modified the

source code in some way since the last time it was compiled, or you
won't even get the Compile menu option.

Yeah, but RTL said he had compled it numerous times, so I'm assuming he did
make some change to the code.

 

[Tom Wickerath]

Hi Lynn,

In his first message, Rich indicated that he was making some change to the code. This would have
forced a recompile the next time the code was run, without him necessarily knowing about it:

"The workaround for this is to copy the line of code that it breaks at, and
paste it to the line below. Then to comment (Remark) out the original line.
Then it works without breaking."

In his second message, he wrote:
"Yes, we have recompiled it repeatedly."

However, he did not say that he had recompiled it after removing a break point. Perhaps these
repeated recompilations all occurred prior to setting & removing a break point.

Tom
_____________________________________

Then of course there's the fact that you have to have modified the
source code in some way since the last time it was compiled, or you
won't even get the Compile menu option.

Yeah, but RTL said he had compled it numerous times, so I'm assuming he did
make some change to the code.