Ivan Prenosil wrote:

>
>>>Can someone explain how updatable view works.
>>
>>The rules will change in V2.0, but the "join hack" will
>>continue to work.
>
> I am not sure I forgot it or overlooked it, but -
> what the new rules will be ?
>

According to the "incompatibilities" document on source forge
http://cvs.sourceforge.net/viewcvs.py/firebird/firebird2/doc/README.incompatibilities.txt?rev=1.6&view=auto
(mind the break)

* Views updatable via triggers no longer perform direct
table operations. In previous versions, a naturally
updatable view with triggers passed the DML operation
to the underlying table as well as executed the triggers.

So if you followed the official documentation and used
triggers to perform a table update, this update was actually
done twice, causing either performance issues or errors (if
blobs were affected). Now availability of triggers turn
direct table updates off and everything depends on your
triggers. If you rely on the legacy undocumented behavior
(e.g. use triggers for logging purposes only), you'll need
to adjust your triggers to perform actual
updates as well.

On the plus side, this change allows triggers to override the natural
operations on views - something that now requires unnatural acts like
joining to RDB$DATABASE. After a minor bump, it was decided that
triggers that support constraints will not disable natural updates,
so adding a declarative SQL constraint to a view does not require
that you also write triggers for all update operations.

However, other apparently innocent triggers - like those that perform
logging or data validation - will stop natural updates. For hand
written systems, that's probably not bad, but a tool that automatically
generates triggers for logging is going to have to be very smart about
simple views.

Regards,


Ann