Subject | false error E_Required_Field if db-server-field is defined not-null with defaul |
---|---|
Author | Frank Emser |
Post date | 2003-03-11T11:43:27Z |
On the database-server, I have a field declared as being not-null,
with a default-value defined
(RDB$RELATION_FILEDS: RDB$NULL_FLAG =1; RDB$DEFAULT_VALUE IS NOT NULL).
As consequence, using a SQL-INSERT-statment explicitely, it is
possible to insert a record without giving a value for that field.
The same is true for "good-old-BDE".
Now IBO (TIBOTable) breaks this behaviour:
It tells me that this field is E_Required_Field.
(Btw. I checked the Required-property of TIntegerField and this is FALSE.)
As a workaround, I added this field to the DefaultValues property of
TIBODatabase. Probably I could live with it, if it suffice to name the
field without a specific value. But defining the default value twice
is redundancy which sooner or later may lead to inconsistency (After
all, we are talking about databases...).
Anyway, why doesn't IBO simply recognize automatically server-side
default-values ?
with a default-value defined
(RDB$RELATION_FILEDS: RDB$NULL_FLAG =1; RDB$DEFAULT_VALUE IS NOT NULL).
As consequence, using a SQL-INSERT-statment explicitely, it is
possible to insert a record without giving a value for that field.
The same is true for "good-old-BDE".
Now IBO (TIBOTable) breaks this behaviour:
It tells me that this field is E_Required_Field.
(Btw. I checked the Required-property of TIntegerField and this is FALSE.)
As a workaround, I added this field to the DefaultValues property of
TIBODatabase. Probably I could live with it, if it suffice to name the
field without a specific value. But defining the default value twice
is redundancy which sooner or later may lead to inconsistency (After
all, we are talking about databases...).
Anyway, why doesn't IBO simply recognize automatically server-side
default-values ?