sgoodhall at comcast.net
sgoodhall at comcast.net
Wed Aug 2 10:54:01 CDT 2006
There can be a couple of issues here. One is as stated, if you have "On Error Resume Next" active when you invoke a sub or function then errors in the lower level routine will kick back to the upper level. The other issue is that if you invoke a method in a class module, even without On Error active, what happens depends on the setting Error Trapping option in VBA. If Error Trapping is not set to "Break in Class Module" then the error will be trapped in the routine that invoked the method. Regards, Steve -------------- Original message -------------- From: "Bobby Heid" <bheid at appdevgrp.com> > 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----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Wednesday, August 02, 2006 11:14 AM > To: AccessD > Subject: [SPAM SUSPECT] [AccessD] Error Trapping > Importance: Low > > > 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 > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com