At 03:46 PM 10/18/2004, paulruizendaal wrote:

>It is a while since I've looked at this, but my recollection of
>Oracle's way of doing it is:
>
>- On tables you can specify BEFORE and AFTER triggers

But only one of each, I think

>- On views you can specify INSTEAD OF triggers
>- BEFORE and AFTER won't work with views
>- INSTEAD OF won't work with tables
>- Some views can be updated. If an updateable view has
> a trigger (which must be of type INSTEAD OF), 'natural'
> update is disabled/foregone
>
>The above sounds like a logical and sound design to me. Also, it
>seems to be compatible with the rules that Dmitry put forward (see
>Ann's earlier post).

Under the Oracle model how would you handle the logging case
I described originally? There's a trigger on a view, but it
does not affect the parent table, only records the action in
a log table. Why should that disable the 'natural' update?

> Perhaps
>we should not signal that natural update is switched off, but signal
>that it should be switched on. Something like:
>
>CREATE [UPDATEABLE] VIEW ...

In the absence of 10 years of history, I'd agree with you. However
for 10 years, the default state of simple views has been UPDATEABLE.
Reversing that policy now will (in all probability) cause working
updates to fail if your model is adopted. In the current state of
Firebird 2 the updates don't occur - no error, not hint.


Regards,


Ann