> > > Have you tried having that logic in a stored procedure and calling
> > it from
> > > the triggers for the different tables? As per documentation, you
> > can only
> > > use one table with CREATE TRIGGER.
> > >
> >
> > The logic is already stored in a separate SP.
> > What could be interesting is if a procedure can be called with
> > implicit parameters avoiding to pass it all the NEW.fields that must
> > be managed.
> >
> > The problem now is that I have to create plenty of triggers executing
> > exactly the same SQL code but differing only by the table they are
> > assigned to.
>
> This is the only way to go. The definition of a trigger can only be done
> for ONE table and ONE data manipulation operation at the same time. So
> if you want to track changes for 5 different tables, then you must create
> triggers for each data manipulation (delete, insert, update) on each of
> these tables.
>
> Btw, if you want to track *committed* changes, then use AFTER [OPERATION]
> triggers instead of BEFORE [OPERATION] triggers.

I do not believe that AFTER [OPERATION] has anything to do with COMMITting -
they will fire just, eh, after the operation :)

Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com

Upscene Productions
http://www.upscene.com

"This is an object-oriented system.
If we change anything, the users object."