Random Shutdown of Access Application

[baloos]

Help !

The MS Access 2000 application I have developed for my remote client, when deployed, occasionally shutsdown with no error message and no clue as to why.

There is no common pattern that I can establish. Compact and Repair makes no difference. Have tried re-writing objects that I suspect may cause this. I have tried creating new front end and back ends and re-importing all the objects. Have tried programatically deleting and replacing all queries. Have tried converting to Access 2003 and back again.

Is there any third party trace tool that I could use, or expertise that I could engage?

My London based client is losing patience and I am staring down the barrel of 4 weeks worth of work going unpaid.

Thanks in anticipation...

--
Richard

 

[RuralGuy]

Is your client using an MDE? It seems to me, that could be one of the symptoms of an unhandled error in an MDE.

 

[baloos]

No. It is not running as an MDE.

Thanks for replying though. I will appreciate any suggestions.

 

[RuralGuy]

Does the client have full Access or just the run time extensions? What version are they running?

 

[The_Doc_Man]

Two factors may be coming together here.

Factor one - as Rural Guy suggests, errors. But they may be HANDLED errors if there are no messages issued.

Factor two - remote... as in, not on your office local area network... Access will shut down when it loses connection to its MDB file. I am reminded of the movie Cool Hand Luke - "What we have here is a failure to communicate." In this case, your client's copy of Access with something on the machine hosting the database files. A network timeout would do this. The only way to know if this is correct, though, is to use a WINDOWS account (not an Access account) that has Admin rights on the client machine so you can look at the event viewer. Network object timeouts are logged in one of the log files - probably SYSTEM, probably not APPLICATION - but it wouldn't hurt to examine the log files for events in the same time frame as one of these mysterious failures.

 

[baloos]

Doc Man,

My client asked their IT people for the event logs, after another crash.

The IT department sent them three fiiles..
sec020407.evt
evt020407.evt
sys020407.evt

I have tried to open them using Wordpad, but it is all gobldygook!

Is there a viewer application that will make sense of them?

Thanks

--
Richard ( Not a Grandpa yet AFAIK, but beginning to feel like one)

 

[pbaldy]

Try Event Viewer in Control Panel/Admin Tools.

 

[baloos]

Thanks Paul,

I have opened the log files. Nothing showing for the time that the application shut down, so, where do I go from here??

All the user's machines have Access 2000. Is it worth converting it to Access 2003, and using developer extensions, to release it to the client as a run time app?

I am not going to get many more throws of the dice.

Have been programming MS Access since version 1.1. Never been stuck like this before.

--
Rich

 

[The_Doc_Man]

If there are no log files then you may have a little "gotcha" somewhere in the code. Access just doesn't exit like that without making a log entry unless the event was one it didn't think it had to log.

Open each module in turn and search for ".Quit" (and ".QUIT" and ".quit") in various contexts. If there are macros, check them for a QUIT. If you find such items, look at what is around them to see if they are responses to an error condition. If so, you have found your gremlin.

 

[MicroE]

Access will shutdown if the application is running in Runtime mode and an untapped error occurs.

Make sure EVERY procedure and function has an error trap. DON’T use macros (unless they are for a Menu)


Sub Test()
On Error GoTo Err_Trap

'Your Code

Err_Trap_Exit:
Exit Sub

Err_Trap:
MsgBox Err.Description
Resume Err_Trap_Exit

End Sub

 

[boblarson]

Access will shutdown if the application is running in Runtime mode and an untapped error occurs.

As The_Doc_Man has said, an untrapped error will generate a message saying that an unhandled error occurred, so this problem that they are experiencing is not generating a message, it is just shutting down. So, that would tend to indicate that it is being handled, but that it isn't necessarily being handled properly to keep the project open.

 

[MicroE]

Sorry - I should have said "Access may shutdown" instead of "Access will shutdown".

Calls to Windows dlls do not raise exceptions and the environment could be configured not to message users if a run-time exception occurs.

Also, if you are developing in Access 2003 and the users have Access 2000 – Access 2003 will let the developer reference options that are not available to 2000 users (even though the db is in a 2000 format). For example - the OpenArgs argument in Docmd.OpenReport - works in 2003, but not 2000.

So it is important to make sure ALL procedures are error trapped. I would suggest installing Access 2000 on your PC - so the development platform matches the user’s environment. (I have every version of Access from 2.0 and up loaded on my PC).

 

[baloos]

I have used MS Access 2000 to develop this application.

From experience, I have in past developments experienced random and seemingly untraceable errors, 1571 errors for example, other corruptions, and problems associated with the Project file becoming detached from the application, where you get a message to the effect that it can't find the project or library.

Like most regular MS Access developers I imagine, every new DB starts out as a copy of one of my previous developments, whichever one most closely fits the bill. Its quite possible that I have been carrying a corruption of some kind since Access 2.0. It just manifests itself in different ways.

Where I have experienced problems like this, and a compact and repair doesnt fix it, I create a barnd new blank database and import all of the objects from the existing one. On all previous occasions this either fixes it, or it highlights the corrupt object, because there is a long delay in the import or the import falls over.

I did a search for ".Quit" as was suggested above, and found one that wasn't intended in a 3rd party class module (GroupWise so that my app can send email). I commented out this line of code, rereleased to the client, but it's still shuts down, no message. I have put trace statements on every button click, and on every form activate which write a trace record. The exported traces have no common pattern.

My next move will be to ensure every sub or function has an error trap. At the moment only the more complex ones do. Also, will release it to them as an Access 2003 runtime, instead of 2000.

For Save and Cancel operations I use Docmd.Domenuitem statements where the Version I use is "A_MENU_VER20". Ancient way of doing things but I have always subscribed to the "if it aint broke dont fix it" methodology.

But it is broke, and I dont know why, so even considering changing this too.

Any miracle cures welcome !

--
Richard

 

[boblarson]

Actually, you should probably replace the DoCmd.DoMenuItem codes because Microsoft specifically deprecated them and the use of them in newer versions are not supported and highly discouraged. Use the equivalent DoCmd.RunCommand acCmdxxx instead.

 

[MicroE]

For bound forms, in place of the docmd object for saving the current record, I use:
If Me.Dirty Then Me.Dirty = False

Could the 3rd party class module be causing the issue? For example - what if the email server name is incorrect within the application and the class module is not handling the exception correctly? How is the class module disturbed to the user (within the app or an external file / control)?

Try a decompile of the application. http://www.fmsinc.com/free/newtips/access/accesstip7.asp
I would suggest running the decompile from one of the user’s PC – they may receive an error you don’t.

I would also ask the client what service pack of MS Access 2000 they have installed?

FMS has a product to Analyze an Access DB.
http://www.fmsinc.com/products/analyzer/index.html

Lastly – is the database split with a FE installed locally on each user’s PC?

 

[RuralGuy]

Actually, you should probably replace the DoCmd.DoMenuItem codes because Microsoft specifically deprecated them and the use of them in newer versions are not supported and highly discouraged. Use the equivalent DoCmd.RunCommand acCmdxxx instead.

And if you need a reference then I use this one: Converting DoMenuItem to RunCommand