Debugging Access 2002 vs 97

[Richard Cleaveland]

I have been comfortable debugging VBA modules using Access 97. I recently
acquired Office XP and converted my applications to Access 2000. In general
they seem to run fine, but there's a bug in one (which may have been there
before conversion).

I now find that I can't get started debugging modules in 2002. If I call up
a module from a form I get the VBA in a new window; that's not very
troublesome. BUT when I insert a breakpoint in the code the procedure
doesn't stop there - just goes on and completes.

I've seen references to "break mode" in the help system, but when I click on
that button nothing seems to happen.

I sure could use some help in "getting over the hump" so I can get on with
bug-fixing.

[Wayne Morgan]

Is it possible that the line that the break is on just isn't being executed?
Have you tried placing the break earlier in the procedure on a line that you
are positive is being executed and stepping through the procedure?

As a work around, you may be able to insert a Stop statement or Debug.Print
statements to see what is happening.

Try importing everything into a new MDB file, compile the new file, and see
if that works. If so, and if you want to keep the old file, you may be able
to decompile the code in the old file to clean out the problem. If you
attempt this, do it on a copy of the file for safety. Open the file using a
command line similar to the following:

"<path>\Msaccess.exe" "<path>\FileName.mdb" /decompile

Add any other switches you may need for your file (i.e. user name, workgroup
file name, password, etc). Once the file is open, enter Alt+F11 to open the
code window and go to Debug|Compile to recompile the code. Next, do a
Compact and Repair.

--
Wayne Morgan
MS Access MVP
"Richard Cleaveland" <Ne************@rgcle.com> wrote in message
news:tI********************@comcast.com...

I have been comfortable debugging VBA modules using Access 97. I recently
acquired Office XP and converted my applications to Access 2000. In
general
they seem to run fine, but there's a bug in one (which may have been there
before conversion).

I now find that I can't get started debugging modules in 2002. If I call
up
a module from a form I get the VBA in a new window; that's not very
troublesome. BUT when I insert a breakpoint in the code the procedure
doesn't stop there - just goes on and completes.

I've seen references to "break mode" in the help system, but when I click
on
that button nothing seems to happen.

I sure could use some help in "getting over the hump" so I can get on with
bug-fixing.

[Richard Cleaveland]

On 2-Feb-2006, "Wayne Morgan" <co***************************@hotmail.com>
wrote:

Ref: number1.nntp.dca.giganews.com comp.databases.ms-access:849938

Is it possible that the line that the break is on just isn't being
executed?
Have you tried placing the break earlier in the procedure on a line that
you
are positive is being executed and stepping through the procedure? I'm positive it's being executed. Since writing the above I have
reinstalled Access 97 and used the original copy of one of the applications;
the processing stops there.
As a work around, you may be able to insert a Stop statement or
Debug.Print
statements to see what is happening. A stop didn't work; haven't tried the debug.print, but the likelihood of
that working in the face of the other indications seems low.
Try importing everything into a new MDB file, compile the new file, and
see
if that works. Compile? I thought the compile was automatic. I don't find "compile" in the
help system. Anyway, a reconversion gives the same result.

<snip> --
Wayne Morgan
MS Access MVP
I can't help but think there's some preliminary step I have to go through in
order to get Access to allow me to debug or recognize breakpoints - like set
a mode or something. I DID hit that "break" icon on the VB window toolbar.

Dick
"Richard Cleaveland" <Ne************@rgcle.com> wrote in message
news:tI********************@comcast.com...

I have been comfortable debugging VBA modules using Access 97. I
recently
acquired Office XP and converted my applications to Access 2000. In
general
they seem to run fine, but there's a bug in one (which may have been
there
before conversion).

I now find that I can't get started debugging modules in 2002. If I
call
up
a module from a form I get the VBA in a new window; that's not very
troublesome. BUT when I insert a breakpoint in the code the procedure
doesn't stop there - just goes on and completes.

I've seen references to "break mode" in the help system, but when I
click
on
that button nothing seems to happen.

I sure could use some help in "getting over the hump" so I can get on
with
bug-fixing.

[Wayne Morgan]

I've never had to set anything as a "preliminary" to get a break point to
work. When the code reaches the break point, it stops and pops up in the
coding window.

--
Wayne Morgan
MS Access MVP
"Richard Cleaveland" <Ne************@rgcle.com> wrote in message
news:FP********************@comcast.com...

I can't help but think there's some preliminary step I have to go through
in
order to get Access to allow me to debug or recognize breakpoints - like
set
a mode or something. I DID hit that "break" icon on the VB window toolbar.

[Richard Cleaveland]

Well, Office 2003 should arrive today - maybe I'll have better luck with it.

Dick

[RoyVidar]

Richard Cleaveland wrote in message
<tI********************@comcast.com> :

I have been comfortable debugging VBA modules using Access 97. I recently
acquired Office XP and converted my applications to Access 2000. In general
they seem to run fine, but there's a bug in one (which may have been there
before conversion).

I now find that I can't get started debugging modules in 2002. If I call up
a module from a form I get the VBA in a new window; that's not very
troublesome. BUT when I insert a breakpoint in the code the procedure
doesn't stop there - just goes on and completes.

I've seen references to "break mode" in the help system, but when I click on
that button nothing seems to happen.

I sure could use some help in "getting over the hump" so I can get on with
bug-fixing.

I'm not sure, but you might want to check the Use Access Special Keys
thingie in the Tools | Startup. I think if this is set, also the
AllowBreakIntoCode property, which I suspect is causing this, is also
set.

Alternatively try the following, to do it through code

dim db as dao.database
with db
.Properties("AllowBreakIntoCode") = False
.Properties("AllowSpecialKeys") = False
end with

--
Roy-Vidar

[David W. Fenton]

"Wayne Morgan" <co***************************@hotmail.com> wrote in
news:sI*******************@newssvr21.news.prodigy. com:

I've never had to set anything as a "preliminary" to get a break
point to work. When the code reaches the break point, it stops and
pops up in the coding window.

The code can't be already executing at the time you set the
breakpoint, however. One of the things that I don't like about A2K
and its successors is the way that code is considered to be
executing at times that it was not in A97 and before. Actually, it's
probably more a function of the separate VBE window, which allows
you to view code in contexts where A97, having only one window,
would not allow it.

The solution may be to open the form or report in design view, go to
the code window, set the break point, save the object, and *then*
open it and execute the code. It may be that you have to bypass your
startup routines to avoid executing code that would prevent the
addition of breakpoints.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"Richard Cleaveland" <Ne************@rgcle.com> wrote in
news:9I******************************@comcast.com:

Well, Office 2003 should arrive today - maybe I'll have better
luck with it.

I doubt it. It's just an upgrade to A2K, which introduced the
independent VBE window, and introduced these kinds of problems with
code execution seeming to be out of synch with what you're seeing in
the application window. I've found this annoying from the first time
I ever used A2K.

On another note, the fact that it works in A97 and doesn't in A2K
does not mean everything was OK in A97. You could have compiled code
corruption in your A97 MDB that is masking an underlying compile
error. That was the basis for suggesting a decompile, though I think
you should do it in the A97 version. While it's extremely unlikely
for compiled code corruption to survive the conversion from A97 to
A2K, the hidden code corruption in A97 could make you think that the
problem was with A2K, when, in fact, it is A2K that is doing it
right and revealing a problem that was hidden in A97.

As to compiling, yes, there's automatic compilation, but I turn it
off. In the Access 97 options (and the A2K+ VBE options) I would
always turn off COMPILE ON DEMAND, which reduces the number of times
code compiles without you're requesting the compile explicitly. I
always keep the COMPILE button on my toolbar in code view, and
compile after nearly every code edit. This flushes out any problems
with my new code as soon as I've made them, rather than waiting for
an automatic compile to reveal them.

Last of all, read this article:

http://trigeminal.com/usenet/usenet004.asp?1033

Take note that the first major heading is "VBA and the 11 Stages of
Compilation." That gets your attention, eh? :)

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Richard Cleaveland]

Hoooooray! - that did it. THANK YOU!

Dick
On 2-Feb-2006, "RoyVidar" <ro*************@yahoo.no> wrote:

I'm not sure, but you might want to check the Use Access Special Keys
thingie in the Tools | Startup. I think if this is set, also the
AllowBreakIntoCode property, which I suspect is causing this, is also
set.