Subject | Re: [Firebird-Architect] NOT UPDATABLE fields |
---|---|
Author | Ann W. Harrison |
Post date | 2005-03-02T16:12:07Z |
Claudio Valderrama C. wrote:
somewhat on the implementation. If, for example, there's a way to get
the "updateablity" of a field easily - as one can now get the
"nullability" - then there isn't a problem. If the check is implemented
as a trigger that validates only that new.<field> = old.<field>, then
there's no problem. If, however, there is not easy way to verify the
updatability, and we have some check that actually catches and rejects
an effort to update the field, even if the value is the same,
sophisticated tools are going to fail.
Regards,
Ann
>Excellent point, and one that I hadn't considered. Of course it depends
> The suggestion for UPDATES seems dangerous. Suppose a GUI and some
> sophisticated connectivity layer (examples abound). From each record shown,
> the user changes one or two fields, then the library can have a prepared
> UPDATE statement ...
somewhat on the implementation. If, for example, there's a way to get
the "updateablity" of a field easily - as one can now get the
"nullability" - then there isn't a problem. If the check is implemented
as a trigger that validates only that new.<field> = old.<field>, then
there's no problem. If, however, there is not easy way to verify the
updatability, and we have some check that actually catches and rejects
an effort to update the field, even if the value is the same,
sophisticated tools are going to fail.
Regards,
Ann