Adriano dos Santos Fernandes wrote:

>I want something that work for all users and is easy to do (like NOT
>NULL) that will prevent problems in future database maintenance.
>Also, applications with generate dialogs based in the metadata can
>understand.
>
>Many programs can benefit from it.
>For example, value of financial or accounting movement can't be changed.
>
>
>
>

On reflection, I don't like this feature for two reasons. First, I
consider it unnecessary. Constraints exist to protect data integrity,
not servce as a censor for application programs. If you don't want your
application to reference a field, don't reference the field. While the
database may legimately care whether or not a field is changed and under
what circumstance it may be changed, I don't think it should do so my
limiting DML. Second, I consider the feature unwise. Best of
intentions aside, circumstances are going to exist where you are going
to change your mind. Maybe the requiements on an application will
change, or somebody will screw up and an ad hoc program to fix things
will be required. When this happens, and it will, you will need to
disable this feature, and, not having learned your lesson, will want to
re-enable it later. This is going to chew up record format versions, a
scarce resource. With effort, we could work around that, but requiring
a global change (or changes) to the database metadata so can application
administrator can escape from the corner that he's painted himself into
doesn't strike me a clever design.

Triggers have a cheap mechanism to enable/disable them. In
Netfrastructure, I took this a step further and added trigger classes
that allow whole classes of triggers to be enable or disabled on a
session by session basic. This is the direction that I think Firebird
should go. If you think that disabling changes to a field is a good and
useful feature, build in a suitable mechanism to control its application
that doesn't require global changes to the databasea metadata.