Error Handling

S

Shell

In Access 2000, I know I can create procedure error handling. That is the
scope of the error handling is restricted to the function or sub.

But, can I create a global error handler that is always on the look out for
a specific situation?

thanks
 
S

Shell

That's not what I meant by global. Writing a link in each routine to a
global routine is counter-productive. I wanted to set up a global event
handler.
 
D

Douglas J. Steele

I disagree that it's "counter-productive".

In any case, I don't believe what you want to do is possible.
 
A

Arvin Meyer [MVP]

Dirk Goldgar said:
Until recently I didn't think it was possible, but have you seen this?

http://www.everythingaccess.com/simplyvba-global-error-handler.htm

It still requires a single line reference to it in each procedure. That's
all my code needs as well. Allen's code does the same. The difference I
think is that mine creates an external error log which it will create on
first use, and Allen's writes the log to a table within the database. I
chose to do it my way in case the database was corrupted, the user could
just email me the plain text file.
 
D

Douglas J. Steele

Dirk Goldgar said:
Until recently I didn't think it was possible, but have you seen this?

http://www.everythingaccess.com/simplyvba-global-error-handler.htm

It costs real money, though. I haven't tried it, but I gather it works.

Oops. I forgot about that, and I actually was one of Wayne's beta testers
last year! While it worked flawlessly, I didn't see enough justification to
go through the extremely painful process to bring products like that into
our corporate environment, especially since I didn't think it would be
approved. Guess since I'm not using it, it totally slipped my mind..
 
D

Dirk Goldgar

Arvin Meyer said:
It still requires a single line reference to it in each procedure.

Are you sure? The text on the website is somewhat ambiguous, but I don't
think it does. I agree that if you have to add a call to it in every
procedure, there's not much point.
 
W

Wayne Phillips

http://www.everythingaccess.com/simplyvba-global-error-handler.htm
Respectfully, I would like to correct you in that the product does _not_, in
general, require any additional code to be added to your procedures - in fact
that's one of the key features of the product.

For a better understanding of how the product works, there is a free
developer edition available to try it out.

Regards,
Wayne Phillips, EverythingAccess.com
 
W

Wayne Phillips

Douglas J. Steele said:
Oops. I forgot about that, and I actually was one of Wayne's beta testers
last year! While it worked flawlessly, I didn't see enough justification to
go through the extremely painful process to bring products like that into
our corporate environment, especially since I didn't think it would be
approved. Guess since I'm not using it, it totally slipped my mind..
Hi Doug,

I completely agree that in most corporate environments, using a third party
DLL for a distributed app is difficult at best. This is something that I am
overcoming in v2 of the product which won't require any DLL at all - all
functionality will be implemented from VBA directly. This will then
hopefully expand our client base to more corporate users.

Regards,
Wayne Phillips, EverythingAccess.com
 
A

Arvin Meyer [MVP]

Hi Wayne,

You should change your website then. It says:

"Activate the global error handler with a single line of code that simply
tells our software how to call your subroutine when an exception is
detected."

And yes, when I get time I'd like to test it if only a single line of code
in the entire database is all that's required.
 
D

Douglas J. Steele

To what would you suggest he change it, Arvin?

Take a look at
http://www.everythingaccess.com/simplyvba/globalerrorhandler/enablinganddisabling.htm

While I'll agree that the function EnableErrorHandler is actually more than
a single line of code, that's only because it includes error checking in
case the initialization doesn't work.

The single call

ErrEx.EnableGlobalErrorHandler(Access.Application, "MyGlobalErrorHandler")

tells Access to call routine MyGlobalErrorHandler any time an error is
encountered.

That's all you need to do: no code anywhere else in the application (except
the code for MyGlobalErrorHandler).

--
Doug Steele, Microsoft Access MVP

(no private e-mails, please)
 
A

Arvin Meyer [MVP]

How about instead of:

"Activate the global error handler with a single line of code that simply
tells our software how to call your subroutine when an exception is
detected."

something like:

Activate the global error handler with a single line of code in the
application that simply tells our software how to call your subroutine when
an exception is detected.

--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com
 
W

Wayne Phillips

Arvin Meyer said:
How about instead of:

"Activate the global error handler with a single line of code that simply
tells our software how to call your subroutine when an exception is
detected."

something like:

Activate the global error handler with a single line of code in the
application that simply tells our software how to call your subroutine when
an exception is detected.

--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

Thanks guys -- I've gone with:

"In the start-up routine of your application, activate the global error
handler with a single line of code that then tells our software how to call
your subroutine when an exception is detected in your code."

Hopefully, that is clearer than the previous version.

Cheers

Wayne Phillips, EverythingAccess.com
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top