I'm using FB 2.1RC1, in case this is regression. I somewhat doubt it is.

An instead-of trigger on a view can make changes that the view itself notices during its execution;
if you wanted (see below) to perform an operation in your trigger based on each row that the user
would have been able to see right before his multi-row update/delete/(insert?) was executed, you'd
be surprised to find the view was mutating as it ran, firing the trigger more/less often than
expected. I'm mostly surprised because I thought it was a general rule that during execution of a
single statement (or at least SELECTs), only data visible at the beginning of the statement would
be used (thus the solution to the "insert into X ... select * from X" problem -- was that actually
a one-off bug fix?)

create table zeta (id integer);
insert into zeta values (1);
insert into zeta values (2);
insert into zeta values (3);
insert into zeta values (4);
insert into zeta values (5);
insert into zeta values (6);
insert into zeta values (7);
insert into zeta values (8);

create table lambda (id integer);

create view alpha as select id from zeta;

SET TERM ^ ;
ALTER TRIGGER ALPHA_DELETE ACTIVE
BEFORE DELETE POSITION 0
AS
BEGIN
insert into lambda (id) values (OLD.ID);
delete from zeta;
END^
SET TERM ; ^

delete from alpha;
select * from lambda;
--> just one (1) row returned, when I would have expected to see 8 (the un-WHERE'd delete would
have deleted all rows during the first trigger execution, then done nothing later, but the inserts
would still have run for each row being passed into the trigger.)
--> same result if we change to an AFTER DELETE trigger; doesn't seem to matter.
--> we don't have "STATEMENT"-level (vs. "ROW"-level) triggers the way Oracle does, so I can't
really prepare a list of things to do and let that trigger "clean up" afterwards.

My actual case will be more complex, I was just testing that it would work. Now I'm not so sure.

(I'm trying to implement copy-on-write via triggers and views; to do so, the view would show the
user "current" data about an entity, including detail records; an attempt to modify that data would
result in a new copy of all information about the entity being created, the user's concept
of "current" being shifted to point to the new version, and their requested changes applied to that
new copy; my fear is that while that should work fine for single-row operations on the views, multi-
row operations may notice the change from previous to next version numbers on the fly, and the view
would then start returning "new" rows for the trigger to run on, which could get confusing, and
worse, might miss some rows, or execute both against the old version of a row *and* the newly
created version, too.)

Thanks,

- Philip Williams