Access (97) has encountered a problem and needs to close

[Stuart]

I have used Access for years, but have never seen this
error occur with the frequency that it is occurring
lately. I can't determine the pattern, and I don't
understand the dumps that are produced. Are there any
resources to help me troubleshoot this, under Access 97
and XP (SP2)?

Thanks, Stuart

 

[Allen Browne]

Stuart, any clues as to the kinds of things that trigger the crashes?

Does it tend to happen when opening a form or a report? A particular one, or
any one?

Does it relate to running a query that contains a subquery?

Does turning of the Windows XP Themes make a difference (Right-click
desktop, and set Themes to "Windows Classic".)

If you have not done so, compact the database (Tools | Database Utilies |
Compact).
Then close it. Check there is no LDB file in the same folder as your mdb.
Make a back up copy, and then decompile the database by entering 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"
Then compact again.
Finally, compile again.

It is also worth making sure that *nothing* else is running that could
interfere with Access. Turn off your screen-saver. Set your anti-virus
program to NOT scan mdb files. Remove everything from the system tray that
does not absolutely have to be there. Check for spyware. For a list of the
things that start whenever you boot, see: Start | Programs | Accessories |
System Tools | System Information | Software Environment | Startup programs.

Presumably you have applied SP2 for Office 97 and also the latest JET 3.5
patch. Search for msjet35.dll. Right-click, and check the Version tab.
Should be at least 3.51.3328.0.

 

[Stuart]

Allen, thank you for your advice, but none of the above
have any effect on the problem. I have decompiled, have
the latest revs, am clean of spyware, etc. but the
problems continue. I can give you specific examples:

1. The code in the onClick event for a button specifies
setting the value of a public variable to the value of a
control on the form. When the value of the control is
null, an error correctly occurs. When I attempt to go
into design mode to deal with this, Access immediately
aborts. This is totally and reliably reproducible.

2. A subform is open in datasheet mode. When using the
filter by form button, an error occurs when a value
selected (which includes a comma) is not enclosed in
quotes. This, by the way, seems to be a bug, as the
access-generated drop down box lists the value. In any
case, after this, manally adding quotation marks,
toggling back and forth between the various filtering
icons eventually results in an access program abort.

3. Occasionally when I press the SAVE button in design
mode, I get an error message saying "The Save Operation
Failed". Pressing it again works, but often soon after
that Access aborts.

Allen, any help you can provide in helping me
troubleshoot would be greatly appreciated.

Thanks and regards, Stuart

-----Original Message-----
Stuart, any clues as to the kinds of things that trigger the crashes?

Does it tend to happen when opening a form or a report? A particular one, or
any one?

Does it relate to running a query that contains a subquery?

Does turning of the Windows XP Themes make a difference (Right-click
desktop, and set Themes to "Windows Classic".)

If you have not done so, compact the database (Tools | Database Utilies |
Compact).
Then close it. Check there is no LDB file in the same folder as your mdb.
Make a back up copy, and then decompile the database by entering 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

 

[Allen Browne]

Hi Stuart

Okay, the common factor here is that you are modifying the code while it is
running - in break mode, while the form is open (not in design view).
Without proof, I suspect that this is corrupting your project and causing
the crashes.

Access keeps 2 copies of the code: the text version (not present in an MDE),
and the compiled version which actually runs. When you modify an object such
as a form, Access creates a temporary copy (so you can revert to the last
saved version of the code). When you begin to modify a form by altering the
code in break mode while it is already open, there are now 4 copies that it
is supposed to keep correctly synchronized, and I believe that it sometimes
gets this wrong. The evidence is that there are times when you make a change
in break mode, but the Compile option on the Debug menu remains disabled,
i.e. Access does not recognise that the project needs recompiling.

We originally noticed this when working with subforms (where it is much more
convenient to change the code in break mode, rather than close the form,
open the subform and its module in design view, locate the line, and make
the changes). Once we twigged what was causing the corruption and stopped
editing in break mode, we found that corruptions in A97 dropped to about 1/4
of what it was previously.

Undoubtedly, your mdb now contains corruption that will not be fixed simply
by a decompile. After another decompile and compact, create a new (blank)
database, and import everything. If one particular form is problematic, you
may want to use the undocumented SaveAsText and LoadFromText rather than
import it directly from the corrupted database.

Regarding the code that passes the value of the control to a global, try:
Call MyFunc(Me.MyTextBox.Value)
so that Access passes just the Value rather than passing an object of type
TextBox.

For other suggestions, see:
Preventing Corruption
at:
http://members.iinet.net.au/~allenbrowne/ser-25.html
Issue #1 you've done.. #2 and #3 do not apply to A97. #5 is the main one.
You cannot prevent some corruptions while developing in A97, but it is
possible to reduce them to about once a week.

HTH

 

[Stuart]

Thank you very much. The rebuild of the database by
importing all objects into a new empty db seems to have
completely cured my project. I was concerned that my
relationships were not maintained, until I realized they
were all in the back-end database and unaffected.

I might mention in passing I am doing this project in
Access97 because that is what the users are using, not
because I particularly want to! Office97 is what I am
encountering out there in the small business world.

Once again, thank you for your help.
Regards, Stuart