> -----Original Message-----
> From: Ivan Prenosil [mailto:prenosil@...]
> Sent: Viernes 7 de Diciembre de 2001 10:39
>
> I prefer software that is doing what it is asked to do,
> rather than such that tries to do me a favor by "anticipating"
> my needs and trying to "help" me by doing some extra work automatically.

So you don't like MS software?
:-)

> - because I know there is this new
> view-automatially-disabled-by-trigger functionality,
> I just need to check few things:

Actually, you stil have to check one thing: please ensure that the
overlapping between the default behavior and your custom trigger happens in
the expected order and I'm not kidding. Also, the current behavior only
allows you to override the view's column if you simply are changing the
value of the NEW.* fields. You cannot access the table's fields that may
have been left out of the view. The view still can be updatable if the
omitted fields are nullable.

> 1) BUGS. It _is_ serious, but is it good reason for changing
> basic behaviour ?
> 2) Sometimes people want to have updatable view with triggers
> that behaves like non-updatable view with triggers.
> (And current "workaround" is to add join to such view.)

Either we follow Jim's advice and provide a means to emulate old buggy
behavior or we stick to the current bug and provide a way to overcome it.
IMHO, it should be easy and brief syntax in any case. I don't buy the full
specification to override on an operation-by-operation basis (one for
insert, other for delete, other for update) because it's making worse a
concept that should be simple.

> (In SQL92, existence of non-updatable _column_ causes that _whole
> view_ becomes non-updatable, e.g. CREATE VIEW V AS SELECT 1,ID
> FROM TAB.

Pardon me, but if anyone wants to clarify what should happen in this case, I
will be very happy. I didn't want to throw this topic now, but since you
did: the view you posted is absolutely non-updatable, at least from IB/FB
perspective. Write triggers, do any trick you want. That view cannot be
updated. When I bypassed the check of the BLR compiler with the debugger,
the engine crashed in EXE because it doesn't know how to assign to
expression nodes. I remember that I could update views with expressions in
IB4. Either my memory is failing (and that trick never was possible) or
something was changed later, because it's enough to have
create view v(b) as select id*3 from tab;
and you can't update it in any way. Or maybe you want to implement updatable
stored procedures?

> I am prepared to accept _good_ arguments that explain where I am wrong.

I still hold that the ability to override semantics should prevail. This is
not a trigger on a table, it's a trigger on a view.

> No stones, please :-)

I have better weapons if you're interested.

C.
---------
Claudio Valderrama C.
Ingeniero en Informática - Consultor independiente
http://www.cvalde.com - http://www.firebirdSQL.org