At 03:26 AM 12/1/01 -0400, Claudio Valderrama C. wrote:

>
>I'm totally sick of those automatically updatable views (aka UV). For what I
>see in ib-support, I'm not alone and others do my trick, too, namely,
>creating a join with a dummy table to force it to be non-updatable.
>
>The problem with UVs is that they don't allow you to take control of the
>actions. You create a trigger for before insert, then that trigger fires,
>but (and here lies the problem), the default action is executed anyway.
>Hence, you are screwed if you want to change the semantics: let's say your
>intention is to write to another table, not to the base table. Unless you
>resort to the dummy join hack, your insertion will go anyway to the base
>table.

This is not the way I designed and implemented views with triggers.
Ann tells me the behavior was changed around the time of Version 4.
[Comments on the general quality of V4 engineering omitted.]

It makes absolutely no sense for "updateable" views to have one
behavior and "non-updatable" views another. The original view
update rules were clear and consistent: A before operation trigger
on view preempts any system level ESP. This behavior is simple,
consistent, intuitive, and powerful.

From an architectual view, I strongly recommend that Firebird revert
to the original semantics PROVIDED a statisfactory mechanism can be
found to preserve the existing behavior for existing systems that
have had to accomodate the existing rules. Perhaps a keyword (say
"preemptive") on triggers that intend to preempt the V6 rules, which
would also preclude the trigger from being defined in an older
version.

Jim Starkey