By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,678 Members | 1,904 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,678 IT Pros & Developers. It's quick & easy.

Determine form/VBA procedure from Access crash dump?

P: n/a
Back in my mainframe days a crash dump could be parsed by hand to
reveal the application program running at crash time as well as the
offset into said program, which combined with a extended program
listing could be used to determine the partcular application program
statement that killed the thing.

I realize this is a totally different world, but is there a way at
least to determine which form had control at access-decides-to-croak
time? I've got a situation in which closing a form kills Access like
a big dog, and I'm stymied. All my tables/recordsets are closed, and
I've even unbound the bound list box that is the only data-aware item
on the form.

Alternatively, is there a way to force Access to step thru it's own
code and into the code of other forms? I've checkpointed all the
Form_* procedures in the invoking form but get no hits. It leaves the
close of the invoked form and never reaches the Form_* procedures of
the invoker, so I'm stuck.

Help!

Mark Loveless
Reluctant Access Programmer
Nov 12 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Mark,
It's a pain, but a class module that is an application scope event handler
can be written which logs significant events as they occur. Then a perusal
of the logs will give some hints as to what was croaking when things went
bad. I have my own code, there may be sample stuff around you can start
from. VBA includes a break mode where you can step through code as it
executes and see where it died.
The smart thing to do is to always write your code using functions instead
of subs so that you can at least return a result code indicating whether the
funciton did what it was supposed to or hosed for some reason. Then when a
function errors out you can log the event code and try to sort out what it
meant.

"Mark Loveless" <ma**@tralfaz.com> wrote in message
news:4a**************************@posting.google.c om...
I realize this is a totally different world, but is there a way at
least to determine which form had control at access-decides-to-croak
time? I've got a situation in which closing a form kills Access like
a big dog, and I'm stymied. All my tables/recordsets are closed, and
I've even unbound the bound list box that is the only data-aware item
on the form.

Nov 12 '05 #2

P: n/a
"Mark Loveless" <ma**@tralfaz.com> wrote in message
news:4a**************************@posting.google.c om...
I've got a situation in which closing a form kills Access like
a big dog, and I'm stymied. All my tables/recordsets are closed, and
I've even unbound the bound list box that is the only data-aware item
on the form.


Do you have any code in the on-close event?

You always place the following command in code:

Stop

The above command will invoice the de-bugger in code. (however, you have
mentioned you are setting break points anyway.....you do know how to set
break points with he mouse in the VB ide...right?

Also, while looking at code..can you do a save and compile all?...you might
have some errors hanging? (can you for example create a mde file?).

It turns out that office DOES in fact do a core dump via Dr. Watson. These
errors (if you choose to hit send) actually get sent to Microsoft for them
analyze.As a results.. if users experience a crash..then MS can fix it in
the next update. While similar to the old days where execute error
occur..what is different is that MS can now get this info in real time (if
you hit send)..

There is also a great article on debugging VBA code.. Lots of great hints
(like how to show the calling program stack of routines called to get you to
a given point).

Check out:

http://www.fmsinc.com/tpapers/vbacode/Debug.asp
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.attcanada.net/~kallal.msn
Nov 12 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.