Daniel,

>This shouldn't be a problem. If you look at Doug's code, it checks if there's already an error handler. If yes, he simply calls the active error handler with the correct parameters. In your case, the trigger's ON ERROR statement will be called and everything should work as expected.

I did not mean to say this was a huge problem, but rather that people should be aware that there are some things to take care of. I think the example doug gave is a valid one and I sincerely think this should be used whenever coding in error events.

However,Personally I think this still is a pita to code this for every error event, therefore I stay away from coding in error events as much as possible.

Walter,

>HTH
>>David,
>>
>>PMFJI, but there is one thing people should be aware off. The RI mechanism in the standard VFP RIBuilder (and my TaxRiBuilder for that matter) rely on the ON ERROR mechanism.
>>
>>If in an object with code in the error event triggers the RI code in the database, you'll have to handle the cases that error event fires because of errors in the RI procedure. I think this also has been pointed out by doug hennig in one of its articles on his website.
>>
>>Therefore I tend to use error events only in cases where absolutely needed and there where there is no chance of intermixing it with the ON ERROR handler.
>>
>>Walter,
>>
>>>I'm sorry, but there's nothing unfortunate about an object being fully in control of any errors that occur within the code of the object itself. That is the way things should be in a good object-oriented language.
>>>
>>>>As you already figured out, there is no way and that's unfortunate. I was caught by this behavior couple of times... I'm not sure, we can wish about it for Toledo, because adding ability to switch will break the existing code...