| Subject | Re: seems bug : Field accepts NULL Values (empty string) even if it is defined with not null constraints ?? |
|---|---|
| Author | Svein Erling |
| Post date | 2004-03-16T11:44:14Z |
--- In firebird-support@yahoogroups.com, Jonathan Nev wrote:
string fields. But it is not all too difficult to think of a situation
where null can be useful even for strings. E.g. in Norway every person
has a PIN. It is not a number since leading zeroes do count (in fact,
it starts off with DDMMYY). Imagine a company which only shipped
within Norway, but accepted orders from all over the world. Then there
could be a distinction between an empty string (does not have a PIN -
i.e. foreigner) and NULL (PIN number unknown).
Hence, I think SQL is right in distinguishing NULL and an empty field.
At the same time, I'm glad that IBO (and hopefully other components as
well) has an option for setting BlankIsNull.
Set
> Svein Erling wrote:For the programs I write, yes, I generally don't need null for my
>
> >I strongly disagree, NULL simply means "unknown". I know that my
> >wallet is empty (0),
> >
> For numeric fields I agree. But don't you agree that for string
> fields, this distinction is meaningless?
string fields. But it is not all too difficult to think of a situation
where null can be useful even for strings. E.g. in Norway every person
has a PIN. It is not a number since leading zeroes do count (in fact,
it starts off with DDMMYY). Imagine a company which only shipped
within Norway, but accepted orders from all over the world. Then there
could be a distinction between an empty string (does not have a PIN -
i.e. foreigner) and NULL (PIN number unknown).
Hence, I think SQL is right in distinguishing NULL and an empty field.
At the same time, I'm glad that IBO (and hopefully other components as
well) has an option for setting BlankIsNull.
Set