[AccessD] [SPAM SUSPECT] Error Trapping

Either the error is in the handler or after the handler or you may have
a different problem.  I've seen code fail on the End Sub line and
eventually discovered something elsewhere in the module that wasn't even
in the routine that used an implicit boolean or such and fixing that
made the problem go away. 

Charlotte Foust

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters
Sent: Wednesday, August 02, 2006 8:55 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] [SPAM SUSPECT] Error Trapping

Hi Bobby,

Yes - if there was no handler in B then A would pick it up.  But this
happens when there is a handler in B.  That's the puzzle!

Dan Waters
 

-----Original Message-----
Subject: Re: [AccessD] [SPAM SUSPECT] Error Trapping

I think that the scenario that you posed happens when there is no error
handler in B.  So I think the solution is to have an error handler in
every procedure.

Bobby

-----Original Message-----
Subject: [SPAM SUSPECT] [AccessD] Error Trapping


For a long time I've seen that an error trapped in one procedure may
have actually occurred in a called procedure.  For example, if Procedure
A calls procedure B and an error occurs in B, then the error might get
trapped in A, not in B.  So my error log shows an error trapped in A,
but I need to know that it happened in B.

Is there a way to accurately know which procedure actually triggered an
error?

Thanks!
Dan Waters

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com