Error handling fails in Runtime version on other pc's

[Ohma]

Hello everyone,

I've been asked to try and figure out why a database system my company uses has stopped working on various pc's. On some systems it gives runtime errors while starting up, on some it doesn't. It appears to depend on the version and bits of the system/access version. The most widespread problem occurs for users who only have runtime Access, and no full version, and I'd like to at least manage to resolve this or have an idea what's wrong.

During startup of the accdb file, it runs the AutoExec macro, which opens a form, which generates a runtime error that stops the execution of Access. However, the error message is very minimal and tells me nothing about what exactly causes the error, just that there was one.

(translation of useless error message: "Execution of the program has stopped because a runtime error occurred. The program can't continue and will be closed down.")

I've managed to locate exactly where, in the vba code, the error occurs. This is at a line with just the following.

Call TestorLive

A very basic call to a function defined in a different module. I've equiped the calling procedure, the called procedure and the form in which the calling procedure is stored with error handling and error events. I tested it with 'err.Raise' functions and the 'Application.AccessError()' method and it should provide me with detailed information of the runtime error in question. I also added message boxes before the function call and in the first line of the called routine. However, running it on a system with only a runtime version of Access, I only get the error messages for the errors that I raised myself, and the messageboxes up to the function call. Nothing in the called function itself, nor anything from my error handlers. But the actual error still gives me the same useless error window with no useful information.



Some more background information: The modules of the project have a variety of global variables declared and defined over a variety of modules/classmodules and forms. These include Word and Excel applications and documents. It's generally a bit of a mess, and not really designed in a way that handles variables and their scopes responsibly, but it used to work fine. There are some conditional compile statements in the declaration sections that update definitions with PtrSafe to make it work on both 64 bit systems and 32 bit systems. It connects to a firebird database and has a internal database as well, which work in tandem, but these should not have been used in any way at the point where my error occurs.

Considering all this, I suspected that it's maybe a GPF (general protection fault) or something similar, but I'm not exactly sure, and think that would probably generate a more explicit error message.

Does anyone have any idea what sort of error I might be dealing with, and/or how I can get my error handling to catch the error and give me a bit more detailed information.

[ranman256]

I too have notice crashes on different PCs.
I had to guess where it happens , then I put in msgboxes in various places to capture where it was crashing.
msgbox "call X query"
docmd.openquery "qaXquery"
msgbox "call excel"
docmd.transferspreadsheet....

this helped locate the crashpoint.
turns out some PCs cant run certain tools that others do. (and some functions available in Full access, but wont work in RunTime)

[Ohma]

Yes, I did the same to locate the crashpoint. Sadly, it makes no sense. Just calling a custom procedure shouldn't generate an error, much less one that bypasses all my error handling routines.

I don't think it's a difference in available libraries or something like that, considering that the crashpoint has nothing to do with any explicit action being taking. But thanks for the suggestion.

As said, I think the error has something to do with memory management taking place under the hood of Access. But I haven't found any way yet to put my finger on what might possibly be going wrong.