You can avoid BEFORE UPDATE code with a trick like this (was suggested
to me by Geoff Worboys time ago, hope to remember it correctly):
add a column to your tables like:
CREATE DOMAIN LOCK_FLG_DM AS CHAR (1)
DEFAULT 'N'
NOT NULL
CHECK (VALUE IN ('Y', 'N'));

TRIGGER MYTABLE_BU FOR MYTABLE ACTIVE
...
IF (NEW.LOCK_FLG='Y') THEN
NEW.LOCK_FLG='N';
ELSE
BEGIN
/* your time consuming code here */
END

then in the IB_Query you have to specify a LockSQL, with something like
update MYTABLE set LOCK_FLG='Y' where mytableid = :mytableid

unfortunatly, AFAIK, working only on the server side you can't avoid
after update code to run (you can't move the above code to after
update, since NEW.LOCK_FLG='N' will have no effect).
The forecoming Firebird 1.5 will add native record lock support, so no
dummy updates will be required, and I'm sure IBO will support this
feature.
regards
Marco Menardi

--- In IBObjects@yahoogroups.com, Ale¹ Kahánek <ales.kahanek@n...> wrote:
> Hi,
> I noticed that when using pessimistic locking, the TIB_Query runs dummy
> update like this
>
> UPDATE MYTABLE
> SET MY_PRIMARY_KEY = MY_PRIMARY_KEY
> WHERE MY_PRIMARY_KEY = SOMEVALUE
>
> to lock the row. OK, but as a side effect to this behaviour all
Before and
> After Update triggers are fired. Then when the user posts the edited
> changes, the triggers are fired for the second time.
>
> How to avoid firing the triggers for the first time? The trigger can
start
> time consuming work and there is no need to to the same work twice.
>
> Thanks for your time
> Ales