Access 2003 Crash

[JK Peck]

I have a fairly large Access application that ran correctly in Access
2000. After upgrading to Access 2003 (and recompiling and updating
references), it reliably crashes at a certain point. If I step
through the VBA code, the crash does not occur.

What is different about stepping through code instead of just running
it?

Any idea how to find the cause? I know about where it happens, but
since it is Access itself crashing, finding a workaround is just trial
and error.

[Larry Linson]

Have you used the Office Update to assure that you have all the updates to
Office 2003 (they'd be patches, rather than Service Packs, at this point)
and to Jet 4.0 (it's up to Service Pack 8, for Office 2003)?

"Access itself crashing" isn't normal behavior. I can assure you that is not
in the category of "working as designed". Since there _should_ be nothing
the user can do to cause this, I'd suspect it would be a free incident with
the support team (you could call and ask).

Unless they have a patch that hasn't yet been fully tested and released that
applies, however, I am reasonably sure that one of the things they will
suggest is that you first uninstall Office/Access, and then re-install it,
then run Office update. Whether that will fix the problem or not, it's
something that usually has to be done to eliminate an install error. And,
it's entirely possible that whatever is triggering the crash is some
external function that Access is using, so it might not be something in
Access or Office.

Timing is different when you step through code and when you run it. From a
user point of view, though, there's not really anything we can do about
"timing problems" inside the host (Access, in this case).

But, if you can narrow down where it is happening, if that is in code, and
you post some code around that area, with your best guess at where it
happens, maybe someone could suggest another way to do it that _might_ not
trigger the same consequences. Don't count on that, but it's a possibility.

Larry Linson
Microsoft Access MVP
"JK Peck" <pe**@spss.com> wrote in message
news:bc**************************@posting.google.c om...

I have a fairly large Access application that ran correctly in Access
2000. After upgrading to Access 2003 (and recompiling and updating
references), it reliably crashes at a certain point. If I step
through the VBA code, the crash does not occur.

What is different about stepping through code instead of just running
it?

Any idea how to find the cause? I know about where it happens, but
since it is Access itself crashing, finding a workaround is just trial
and error.

[J Peck]

I did check for updates, and I found none available. My Access version
is 11.5614.5703, and Jet 4.0 SP8.

I suspected a race condition or other timing problem and placed some
alerts in the suspect areas to make the application pause several times
in the code, but the crash still occurs. Some random permuting of code
gave the same result, unfortunately.

I wondered whether single stepping bypassed any optimization in the code
(if there is any when compiling). But I can't really ask users to
single step the code in order to get their job done!

This has occurred on two different recent Access 2003 systems, one on
Win 2K and one on WinXP.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Tony Toews]

pe**@spss.com (JK Peck) wrote:

I have a fairly large Access application that ran correctly in Access
2000. After upgrading to Access 2003 (and recompiling and updating
references), it reliably crashes at a certain point. If I step
through the VBA code, the crash does not occur.

Try inserting some DoEvents in the code.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[Larry Linson]

"J Peck" <pe**@spss.com> wrote

The "build information" you cite is identical to mine, and I haven't had any
similar problems.

This has occurred on two different recent
Access 2003 systems, one on Win 2K and
one on WinXP.

Was this a copy of the same database? Is it happening in an MDB or in an
MDE? Have you tried adding a few DoEvents in the area of code that is
suspect?

Perhaps it is some form of corruption. To get around _that_, the best way
would be to compact and repair your database. If that doesn't help, create a
new database, copy in all the objects _except_ the ones you suspect as
causes, and re-create those suspect ones in the new database.

If that doesn't do it, and someone else doesn't have some suggestions, I
think you may need to contact M'soft support. As I said, with Access itself
crashing, that is not the way it should operate and the user should not be
able to cause it from the database the user creates.

Larry Linson
Microsoft Access MVP

[David W. Fenton]

pe**@spss.com (JK Peck) wrote in
news:bc**************************@posting.google.c om:

I have a fairly large Access application that ran correctly in
Access 2000. After upgrading to Access 2003 (and recompiling and
updating references), it reliably crashes at a certain point. If
I step through the VBA code, the crash does not occur.

Have you decompiled and recompiled?

Have you created a fresh MDB and imported everything into it (from a
decompiled version)?

I've seen problems with compiled code causing crashes with slightly
different versions of the VBA libraries, and decompiling always gets
rid of it.

Of course, in A2K, decompiling is not quite as easy as in A97 (it
doesn't clean out as much gunk), hence the suggestion about
importing into a new MDB.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Larry]

pe**@spss.com (JK Peck) wrote in message news:<bc**************************@posting.google. com>...

I have a fairly large Access application that ran correctly in Access
2000. After upgrading to Access 2003 (and recompiling and updating
references), it reliably crashes at a certain point. If I step
through the VBA code, the crash does not occur.

What is different about stepping through code instead of just running
it?

Any idea how to find the cause? I know about where it happens, but
since it is Access itself crashing, finding a workaround is just trial
and error.

When does this happen? Sound similar to what was happening (Access
2000 and XP both) in my code when opening a form with lots and lots of
subforms. The way I found around it was to leave the subforms with no
object. Then I put a .5 second delay to run the form timer event and
set up the source object there. If you do this and it solves your
problem, you'll have to pay attention to the child and master links.
Access seems to trash them if you have more than one field in the
link.

I hope this helps.

[JK Peck]

Thanks for all these suggestions. After trying all the usual,
including DoEvents to no avail, I inserted SysCmd messages to the
status bar and found that the line of code that triggered the crash
was simply
Me.refresh
after the code had made various updates. And, indeed, commenting out
that line and running Refresh from the menu once the code had
completed did crash.

Now the form in question consists of a main form and a subform. The
code in question only affected the subform, so I created a refresh
function in the subform and called that from the main form code, and I
get the refresh without a crash. The data tables, which are actually
in a linked database, were already getting properly updated.

This suggests to me that the form data structure in memory has gotten
corrupted somehow, but this has at least moved the problem far enough
away that we can get our work done.

[David W. Fenton]

pe**@spss.com (JK Peck) wrote in
news:bc**************************@posting.google.c om:

This suggests to me that the form data structure in memory has
gotten corrupted somehow, but this has at least moved the problem
far enough away that we can get our work done.

My suggestions would get rid of any form corruption.

And it's why I posted them, because form corruption can lead to
Access crashes.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[JK Peck]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message news:<Xn**********************************@24.168. 128.78>...

pe**@spss.com (JK Peck) wrote in
news:bc**************************@posting.google.c om:

This suggests to me that the form data structure in memory has
gotten corrupted somehow, but this has at least moved the problem
far enough away that we can get our work done.

My suggestions would get rid of any form corruption.

And it's why I posted them, because form corruption can lead to
Access crashes.

I would have gotten rid of the corruption if I could, but compact and
repair and even exporting everything to a clean database does not
solve it. I think it is happening dynamically.

While the code change I made gets around the problem, the corruption
is demonstrably still there, since doing a Refresh from the menu bar
still causes the crash.

In fact, I found that as soon as the form is opened, it is corrupted,
i.e., Refresh crashes it. There is a little bit of onLoad and
onCurrent code that is run, but it is pretty innocuous. I'll be
trying to pin this down further.

[David W. Fenton]

pe**@spss.com (JK Peck) wrote in
news:bc**************************@posting.google.c om:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:<Xn**********************************@24.168. 128.78>...

pe**@spss.com (JK Peck) wrote in
news:bc**************************@posting.google.c om:

> This suggests to me that the form data structure in memory has
> gotten corrupted somehow, but this has at least moved the
> problem far enough away that we can get our work done.
My suggestions would get rid of any form corruption.

And it's why I posted them, because form corruption can lead to
Access crashes.

I would have gotten rid of the corruption if I could, but compact
and repair and even exporting everything to a clean database does
not solve it. I think it is happening dynamically.

Compact and repair will hardly ever get rid of code corruption.

Importing will often not.

Only a full decompile will get rid of code corruption.
While the code change I made gets around the problem, the
corruption is demonstrably still there, since doing a Refresh from
the menu bar still causes the crash.
Aha. That's a new one that you hadn't mentioned, which makes me
think it's *not* code corruption at all.
In fact, I found that as soon as the form is opened, it is
corrupted, i.e., Refresh crashes it. There is a little bit of
onLoad and onCurrent code that is run, but it is pretty innocuous.
I'll be trying to pin this down further.

Something about the state it's in when the refresh happens is
causing the problem, obviously. But that makes it very hard to
figure out.

I would say it's probably something to do with data retrieval, not
form corruption.

Is it an Access/Jet back end?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Mark Osterhout]

Has anyone found a solution to this problem? I have the exact same
problem. One form of about eight forms in a medium size database
consistently crashes. I could not determine why. When I read through
this link and tried the refresh through the menu, I get the same crash
every time. This is a database I am developing for a client and it has
held us up for the past two weeks. I have been using Access for about 7
years and not had a similar problem. This is an Access 2003 database
and it is set-up as a front-end back-end. The error names msjtes40.dll.

Any help would be greatly appreciated.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[David W. Fenton]

Mark Osterhout <mo*******@yahoo.com> wrote in
news:41**********************@news.newsgroups.ws:

Has anyone found a solution to this problem? I have the exact
same problem. One form of about eight forms in a medium size
database consistently crashes. I could not determine why. When I
read through this link and tried the refresh through the menu, I
get the same crash every time. This is a database I am developing
for a client and it has held us up for the past two weeks. I have
been using Access for about 7 years and not had a similar problem.
This is an Access 2003 database and it is set-up as a front-end
back-end. The error names msjtes40.dll.

Does it have the problem on all PCs? I have a client with two PCs in
her office and one of the reports crashes Access on the WinXP PC and
runs without problems on the Win98 PC. THe report is not corrupted.
It's something about the interaction of the data source (a SQL
string) and the sorting/grouping in the report that doesn't work
well on the WinXP PC.

It could be a video driver issue, for instance.

My guess is that your problem is something similar. To diagnose, try
these steps:

1. do a SAVE AS to make a duplicate copy of the form.

2. open it. If it crashes, it's probably not corruption in the form.

3. in the copy of the form, remove the datasource and open the form.

4. if it doesn't crash (as it's likely not to), you know that the
problem is with the interaction between the data retrieval and the
form itself.

This speculation on my part is bolstered by your report that the
page fault is occuring in the Jet DLL.

Sometimes you can fix this kind of problem by upgrading your Jet
version. Sometimes you can fix it by rewriting the SQL, or by
changing to a saved query for your datasource (or, if you're using a
saved query, change to using a SQL string saved as the
recordsource). Sometimes you can fix this kind of problem by
updating your video drivers.

Yes, I know that mostly doesn't help! :)

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Mark Osterhout]

David,

Thanks for the post. I found a work-around. Here is a better
explanation of the problem. The form is an order entry form. It has a
tab control with four tabs. The second tab contains two sub-forms. One
for order items and another for miscellaneous items. This is where I
found the problem.
The problem first occurred when the front end was set-up at the
workstations on the network. When the user entered orders, the crash
occurred at random. It might be the first record entered or it might
have been the 10th. It always happened after entering the initial
field, customer name. It never happened when the front end and back end
resided on the same computer. It happened more frequently on slower
computers. The system would return the message MS Access must shut down
and the msjtes40.dll file was named.
After reading this link I tried the Refresh through the menu and it
would cause the exact same crash. I had already checked to make sure I
had the latest service pack for MS Access and that the Jet engine was at
its latest release. I had another form, Order Archive, that was set-up
almost exactly the same way. I tried the Refresh through the menu on
this form and it did not crash. I went back to the original form and
deleted the sub-forms from the second tab, tried the refresh and it did
not crash. I added the order items sub-form back and tried the refresh,
again no crash. I added the second sub-form and tried the re-fresh, it
crashed every time. I changed the record locked property on the second
sub-form to True, tried the refresh and this time, no problem. The rest
was easy, I enter the following code in the on_enter event for the
sub-form;

Me![Order_Misc_Subform].Locked = False

And the on_exit event;

Me![Order_Misc_Subform].Locked = True

That’s it (problem not fixed, but worked around, and the programmer with
another black eye). The jet engine must have a problem opening more
than one sub-form on a tab control.
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[David W. Fenton]

Mark Osterhout <mo*******@yahoo.com> wrote in
news:41**********************@news.newsgroups.ws:

Thanks for the post. I found a work-around. Here is a better
explanation of the problem. The form is an order entry form. It
has a tab control with four tabs. The second tab contains two
sub-forms. One for order items and another for miscellaneous
items. This is where I found the problem.
The problem first occurred when the front end was set-up at the
workstations on the network. When the user entered orders, the
crash occurred at random. It might be the first record entered or
it might have been the 10th. It always happened after entering
the initial field, customer name. It never happened when the
front end and back end resided on the same computer. It happened
more frequently on slower computers. The system would return the
message MS Access must shut down and the msjtes40.dll file was
named. After reading this link I tried the Refresh through the
menu and it would cause the exact same crash. I had already
checked to make sure I had the latest service pack for MS Access
and that the Jet engine was at its latest release. I had another
form, Order Archive, that was set-up almost exactly the same way.
I tried the Refresh through the menu on this form and it did not
crash. I went back to the original form and deleted the sub-forms
from the second tab, tried the refresh and it did not crash. I
added the order items sub-form back and tried the refresh, again
no crash. I added the second sub-form and tried the re-fresh, it
crashed every time. I changed the record locked property on the
second sub-form to True, tried the refresh and this time, no
problem. The rest was easy, I enter the following code in the
on_enter event for the sub-form;

Me![Order_Misc_Subform].Locked = False

And the on_exit event;

Me![Order_Misc_Subform].Locked = True

That’s it (problem not fixed, but worked around, and the
programmer with another black eye). The jet engine must have a
problem opening more than one sub-form on a tab control.

If it's not locked, then the first field in the tab order in the
first record will get the focus.

Are you loading subforms before they are displayed? I'd use the
OnChange event of the tab control to load the subform only when it's
displayed. That's pretty much standard practice for a form with
multiple subforms.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc