No, you can't create a gloal error handler.

For my connection, I alwas used currentdb (it is not clear if you are
talking a JET file share, or a server based applcton here).

Since I always use currentdb, then I never have aprobelm of a variable going
out of scpoe.

On the other hand, if you have errors, you should be dealing with.

However, I ahve ALWAYS given my users a mde file. With a mde, then any
un-trapped error DOES NOT re-set all my global vars (and, while we are at
this...we should advoid globabs anyway).

So, you might consider using a mde (and, alao you likey have long ago split
your database into two parts...right???).

And, I don't see why convering from dao to ado would fix anything in
reagidalrds to un-trapped erros and gloabl vars...how are these two issues
relantde?

Anyway...I would just use a mde..and then un-trapped erroresd don't re-set
your varables (local, or glables are not re-set).

Ops..bumped send key...sorry:

No, you can't create a global error handler.

For my connection, I always used currentdb (it is not clear if you are
talking a JET file share, or a server based application here).

Since I always use currentdb, then I never have a problem of a variable
going
out of scope.

On the other hand, if you have errors, you should be dealing with them.

However, I have ALWAYS given my users a mde file. With a mde, then any
un-trapped error DOES NOT re-set all my global vars (and, while we are at
this...we should avoid global anyway).

So, you might consider using a mde (and, also you likely have long ago split
your database into two parts...right???).

And, I don't see why converting from dao to ado would fix anything in
regards to un-trapped errors and global vars...how are these two issues
related?

Anyway...I would just use a mde..and then un-trapped errors don't re-set
your variables (local, or global are not re-set).