Further testing reveals that the trigger does fire immediately after
the UPDATE statement within the trigger code, and that the context is
preserved correctly, ie local trigger variables from the first pass
are saved and restored as you would hope. Nice one!

I don't suppose its possible to deactivate the trigger for the
duration of the trigger code execution to prevent recursion by
using 'ALTER TRIGGER TRIG_NAME INACTIVE', or some other means, is it?

Thanks,
Steve

--- In ib-support@y..., s.beames@m... wrote:
> Is this true even if the update is done by an "UPDATE <tablename>
SET
> <blah>=<blech> WHERE...." type of statement in the trigger???
>
> --- In ib-support@y..., Helen Borrie <helebor@d...> wrote:
> > At 10:45 AM 26-06-01 +0000, you wrote:
> > >G'day all,
> > > if an after update trigger happens to update the same table,
> the
> > >trigger will be fired again, but does this happen immediately
> after
> > >the update statement is executed, or after the initial trigger
> code
> > >completes?
> >
> > It's not an issue.
> > The After Update trigger fires after the **update** (no
kidding?) -
> updating is finished by then. You can only affect the update
values
> in a Before Update trigger. AI triggers are for doing external
> stuff - writing to other tables, firing events, etc.
> >
> > -- HB
> >
> > All for Open and Open for All
> > InterBase Developer Initiative · http://www.interbase2000.org
> > _______________________________________________________