Access Run Time version crashes on Macro errors etc.

[Ed]

I deployed a runtime version of my Access 2007 database. When a user using
the runtime version gets a Macro error, a window pops-up and all they can do
is click Stop All Macros. When the users clicks the button, Access closes
and they have to start the application all over again. When I get these
errors in the full version of Access, I click Stop All Macros but Access
doesn't close.

I want to stop this from happening to the runtime version users. What can I
do to prevent this form happening? The main error that is causing this to
happen is "Cannot Open Any More Databases". This error occurs if the user
has too many forms already open.

Thanks for any solutions or ideas.

 

[Rick Brandt]

I deployed a runtime version of my Access 2007 database. When a user
using the runtime version gets a Macro error, a window pops-up and all
they can do is click Stop All Macros. When the users clicks the button,
Access closes and they have to start the application all over again.
When I get these errors in the full version of Access, I click Stop All
Macros but Access doesn't close.

I want to stop this from happening to the runtime version users. What
can I do to prevent this form happening? The main error that is causing
this to happen is "Cannot Open Any More Databases". This error occurs
if the user has too many forms already open.

Thanks for any solutions or ideas.

You must have error handling on all things that might raise an error in
the runtime. Macros used to not have error handling so that is why they
were never really used by developers who wanted to use the runtime. They
might have added error handling to macros in 2007 though. I can;t say
for sure because I never use macros and only open 2007 when I absolutely
have to.

Giving the user an MDE instead of an MDB was helpful for this with VBA
code errors. Might also help with macro errors.

 

[Jack Leach]

The only macro that should ever be run from the user end is an Autoexec
macro, and that only for checking references. The logic behind this is
explained here:

http://www.trigeminal.com/usenet/usenet026.asp

Other than that you should always use vba procedures rather than macros, for
the reasons that Rick as explained.

Aside from the Autoexec macro the *only* time I will ever use one is as a
developer tool... to run a public function from a double click rather than
opening the immediate window and typing ?FunctionName()

hth

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)