""Leyne, Sean"" <sleyne@...> wrote in message
news:A7526F20AD81874AB68FC1E51862B4DF07E07D@......

> Martijn,
>
> What problem is there to fix?

I think that Martijn summarized it very well, so I won't repeat. And I'm
forced to do the same than Rob Schuff currently. I'm sick of such behavior.
I consider it a bug introduced at some time in the past by someone unknown
but working for a company that I could try to remember.

Trigger on a view should cancel the default operation. At least for a BEFORE
trigger. Since an AFTER trigger can't affect what's stored, I wouldn't
consider it in the solution. Otherwise, let's just implement a way to
designate a simple view as non-updaable as if it was based on a join.

While we are at it, I seem to remember this case that changed. I'm writing
directly in the newsreader, so forgive the typos please:

create table t(a int, b int);
create view v(x,y) as select a, b*3 from t;
This view isn't directly updatable, right?
Should it become updatable with a trigger? I think that IB4.2 said YES!
set term ^;
create trigger v_t for t before insert
as begin
insert into t(a,b) values(new.x, new.y/3);
end^
set term ;^

insert into v values(4, 18);

IB4.2 => OK
IB6 => Greetings to your mother!

I know the place where it fails in the compilation process. However, I'm not
sure if I have all the info available at this point to make the right
decision and don't complain:
- the thing should be a view
- the thing should have a BEFORE <action> trigger defined
- I'm in doubt in the case of a DELETE: do I require a trigger? Do I need to
validate that there aren't calculated fields or constant fields to let the
DELETE proceed without the need of a B_D trigger?

Those questions are better handled on another forum, but I hope you get the
idea. It's another can of worms, in case you missed the time to open the
Pandora box. <g>

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing