At 10:11 PM 10/01/2008, you wrote:
>On 1/10/08, VS-Polis <[EMAIL PROTECTED]> wrote:
>> If the database column itself is set to "not null" or if this column is
>> part of the primary key, it returns is_nullable as correct value "1" resp.
>> "true". If the database column is defined via domain and the domain is set
>> to "not null", the column value "is_nullable" nevertheless returns
>> incorrectly "1" resp. "true", but not the expected correct value "0" resp.
>> "false".
>
>This is right, imo.
It is wrong. The word "nullable" is not a synonym for NOT NULL, it is the
opposite. A field definition constrained NOT NULL is "non-nullable".
In Firebird, the field RDB$NULL_FLAG in the RDB$FIELDS record shows whether the
column or domain is "nullable" (the default in Firebird): the flag will be
null. Columns and domains that have the NOT NULL constraint have 1 in
RDB$NULL_FLAG. If FbConnection.GetSchema("Columns") really is returning the
wrong result for is_nullable, it might be due to its creator confusing the
meaning of RDB$NULL_FLAG, i.e., a 1 does *not* mean the column is nullable, but
that it is non-nullable.
Note that you cannot assume that being part of the primary key automatically
means a column is non-nullable. Since Fb 1.5 it is possible to have a nullable
column in a composite PRIMARY KEY constraint. It would be worthwhile to
re-check your observation: if the column definition does not carry the NOT
NULL constraint, then it *is* nullable.
Helen
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Firebird-net-provider mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
