Phillip,
This is an interesting complete approach to keeping the summary table in agreement with the details and subdetails. Neat idea. For my purposes, the summary table does not need to be immediately updated, so I can get by setting a field to null in a separate table that just tracks some items on database status.

You mentioned something else that I think will cure my issue with my program dumping thousands of records in causing the trigger to run thousands of times when once is clearly enough. I can disable the trigger! I didn't think of that. It's the fix I need.

Thanks for your help.

Jack

--- In firebird-support@yahoogroups.com, "unordained" <unordained_00@...> wrote:
>
> ---------- Original Message -----------
> From: "JackR" <jack@...>
> > Assuming that it is not a non-issue, is there a way to configure a
> > database trigger to do this update?
> ------- End of Original Message -------
>
> 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
>