Subject | Re: [firebird-support] Maintain Summary Table with Database Trigger |
---|---|
Author | unordained |
Post date | 2010-07-23T15:20:25Z |
---------- Original Message -----------
From: "JackR" <jack@...>
Yup.
create trigger detail_changed for detail after insert or update or delete as
begin
-- in case you change master_id (move detail from one master to another)
-- use both values. probably more efficient ways to do that.
-- avoid updating records that have already been marked, fewer disk writes(?)
update master set fix_me = 1 where id in (new.master_id, old.master_id) and
fix_me is distinct from 1;
end
create trigger fix_master on transaction commit as
begin
for select ... from master where fix_me = 1 into ... as cursor cur do
begin
update master set ... fix_me = 0 where current of cur;
end
end
This will result in record locks, but if you're updating the master no matter
what, using a temp table (rather than a "fix_me" field) won't change that.
Look into the isql options for disabling these triggers first though; if you mess
up fix_master such that it likes to throw exceptions, you could make it difficult
to fix, as you won't be able to commit the new trigger definition!
-Philip
From: "JackR" <jack@...>
> Assuming that it is not a non-issue, is there a way to configure a------- End of Original Message -------
> database trigger to do this update?
Yup.
create trigger detail_changed for detail after insert or update or delete as
begin
-- in case you change master_id (move detail from one master to another)
-- use both values. probably more efficient ways to do that.
-- avoid updating records that have already been marked, fewer disk writes(?)
update master set fix_me = 1 where id in (new.master_id, old.master_id) and
fix_me is distinct from 1;
end
create trigger fix_master on transaction commit as
begin
for select ... from master where fix_me = 1 into ... as cursor cur do
begin
update master set ... fix_me = 0 where current of cur;
end
end
This will result in record locks, but if you're updating the master no matter
what, using a temp table (rather than a "fix_me" field) won't change that.
Look into the isql options for disabling these triggers first though; if you mess
up fix_master such that it likes to throw exceptions, you could make it difficult
to fix, as you won't be able to commit the new trigger definition!
-Philip