Subject Re: [Firebird-Architect] NOT UPDATABLE fields
Author Adriano dos Santos Fernandes
Leyne, Sean wrote:

>Ann,
>
>
>
>>So, the question, as I see it, is do we need a third mechanism?
>>
>>
>
>NO!
>
>What Adriano outlined is an application requirement, not a database
>requirement.
>
>
I don't agree.
1) It's a very common business rule that many types of applications can
benefit from.
2) The engine can use as a hint to reserve less space for record versions.
3) The current options cannot be used by tools and applications that do
metadata inspection.
4) It's more easy to write and more clear to read.

>The missing piece that v2.0 provides is connection or transaction
>context variable which allows for variable to be shared amongst
>separated triggers/SP, without needing to pass them as 'dummy' table
>columns.
>
>
If you are refering to the fact that the flag can be deactivated, this
is not something that I plan to use.
But flexibility is a good thing.


Adriano