Breakpoint problem

[Ammammata]

X-post on three MSAccess related NG
Follow-up set to it.comp.appl.access

It happens that my code stops without any breakpoint set; well, in the
past I toggled a breakpoint on that instruction but I removed it ages
ago.

See screenshot: http://www.bb2002.it/temp/breakpoint.gif

Can't understand why...
Any tip or trick?

Thankyou in advance

 

[Allen Browne]

Access maintains 2 copies of the code: the text version (what you edit) and
the compiled version (what runs.) There are times when these two get out of
sync., and the symptom you describe is one indicator of this problem.

To solve the problem, decompile the database. This discards the compiled
version. Access recreates it automatically, and the synch problem is gone.

To decompile, make a backup copy of the mdb in case something goes wrong,
and enter something like this at the command prompt while Access is not
running. It is all one line, and include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

Prevention. There are several possible causes, but a common one is editing
the code in break mode (i.e. while the form is open and running, not in
design view.) When you modify a form, Access creates a temp copy so you can
revert to the last saved version. It is now potentially juggling 4 copies of
the code (compiled and text versions of current and original.) It
occasionally seems to confuse these copies if you edit the code without
switching to design view first.

For other suggestions on preventing corruption in general, see:
http://allenbrowne.com/ser-25.html

 

[Guest]

Hi Allen,

I've found that this problem seems to happen if one removes a break point
without forcing a re-compilation of the code (which effectively decompiles
any existing code). If I simply insert a space character or hard return, and
save the project then the ability to do a Debug > Compile ProjectName will be
restored (otherwise, the option remains "greyed out"). Recompiling the code
after removing a break point seems to prevent the ghost breakpoints.

Tom

http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________


:

Access maintains 2 copies of the code: the text version (what you edit) and
the compiled version (what runs.) There are times when these two get out of
sync., and the symptom you describe is one indicator of this problem.

To solve the problem, decompile the database. This discards the compiled
version. Access recreates it automatically, and the synch problem is gone.

To decompile, make a backup copy of the mdb in case something goes wrong,
and enter something like this at the command prompt while Access is not
running. It is all one line, and include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

Prevention. There are several possible causes, but a common one is editing
the code in break mode (i.e. while the form is open and running, not in
design view.) When you modify a form, Access creates a temp copy so you can
revert to the last saved version. It is now potentially juggling 4 copies of
the code (compiled and text versions of current and original.) It
occasionally seems to confuse these copies if you edit the code without
switching to design view first.

For other suggestions on preventing corruption in general, see:
http://allenbrowne.com/ser-25.html

--
Allen Browne - Microsoft MVP. Perth, Western Australia.

Reply to group, rather than allenbrowne at mvps dot org.

__________________________________________


X-post on three MSAccess related NG
Follow-up set to it.comp.appl.access

It happens that my code stops without any breakpoint set; well, in the
past I toggled a breakpoint on that instruction but I removed it ages
ago.

See screenshot: http://www.bb2002.it/temp/breakpoint.gif

Can't understand why...
Any tip or trick?

Thankyou in advance

 

[Allen Browne]

Thanks, Tom

I haven't experienced that, but you may be right. The fact that the compile
state does not change hints agrees with your experience that this could be a
cause.

 

[Ammammata]

Allen Browne has brought this to us :

To decompile, make a backup copy of the mdb in case something goes wrong,
and enter something like this at the command prompt while Access is not
running. It is all one line, and include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

done, but...

running the code I get a "Compile error. Loading DLL"
of course the DLL name is not printed...

going back to the 'bugged' version

 

[Allen Browne]

Does this error prevent you from performing the decompile, or does it occur
in a particular module (form?) of the database after the decompile?

The error does indicate that there is a corruption in the database. Time to
get Access to rebuild it. Follow the steps for the first symptom in this
article:
http://allenbrowne.com/ser-47.html
Then run the decompile again at the end of the process.

Post back if you are still getting the error after this, and indicate at
what point the error occurs.

 

[Ammammata]

Allen Browne explained on 24/11/2005 :

Does this error prevent you from performing the decompile, or does it occur
in a particular module (form?) of the database after the decompile?

thankyou for the quick reply
I decompiled it, the error comes running again the code

The error does indicate that there is a corruption in the database. Time to
get Access to rebuild it. Follow the steps for the first symptom in this
article:
http://allenbrowne.com/ser-47.html

I'm already checking my system with cc_pkg.exe that found some errors
in Registry Details (mismatch and notfound); now I'm working on these
errors

Then run the decompile again at the end of the process.

I'll do

Post back if you are still getting the error after this, and indicate at what
point the error occurs.

sure. thankyou

 

[david epsom dot com dot au]

The incremental compiler is too clever by half (at least in A2K)

I see that when I import library code into a new module the
editor can see it is there (ctrl F2 takes me to the code),
but the compiler doesn't realise that the compilation status
has changed, and continues to take me to the old code even
after I've used the 'compile' menu option.

I notice that when MS added 'true compilation' to VB5, they
said that a typical VB program spent 95% of it's time in
library code, rather than in your VB source code, so if the
compiled code ran in zero time, the maximum benefit would
typically be around 5%.

Bring back fully interpreted BASIC...

(david)

 

[Guest]

Allen and David:

I forgot to mention last night that I also disabled the Compile on demand
option a long time ago, based on advise given to our Access user group by
none other than Sir Michael Kaplan (Michka). See the topic "Avoid Compile on
Demand" on this page:

http://www.access.qbuilt.com/html/gem_tips.html#VBEOptions


David: This might explain your observation:

"...but the compiler doesn't realise that the compilation status has
changed, and continues to take me to the old code even after I've used the
'compile' menu option."


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________


:

Thanks, Tom

I haven't experienced that, but you may be right. The fact that the compile
state does not change hints agrees with your experience that this could be a
cause.

 

[david epsom dot com dot au]

http://groups.google.com.au/group/c..._frm/thread/ccd69afc4dbbd517/e787affdab631ab5

"Turning off compile on demand will make this never happen, fwiw."
Jun 23 1999

I have compile on demand turned off, and it did happen.

However, I am using A2000 (VBA6) rather than A97 (VBA5).

(david)