Subject | Re: [firebird-support] Re: seems bug : Field accepts NULL Values (empty string) even if it is defined w |
---|---|
Author | Jonathan Neve |
Post date | 2004-03-16T13:01:33Z |
Tim Ledgerwood wrote:
also very different from an empty string.
existing systems already work that way (make this distinction). But
still, you must agree that in practice this distinction isn't very useful...
Jonathan Neve.
>>Absolutely! A bug in that it defines a useless distinction that wouldKind of ironic, since ASCII 20 is (IIRC) a space. And yet a space is
>>forever be a nuisance for every database developer! :-)
>>
>>Jonathan Neve.
>>
>>
>>[Non-text portions of this message have been removed]
>>
>>
>
>Nope, sorry, I disagree. I write software that interfaces to a variety of
>hardware, using Delphi. The protocols (like the ISO 8583 protocol for EFT)
>are bitmapped fields - in other words, there is an array of bits that
>indicate the presence or absence of fields in the protocol string. I often
>store what is sent and what is received in DB tables.
>
>An empty string is (IIRC) ASCII 20.
>
also very different from an empty string.
>A NUL is ASCII something else.Well, I guess what you're saying is that it's inevitable, because
>
>God help you if you get it wrong ... you'll have users chasing you with
>axes all over the continent of your choice ...
>
>Nope, in a real, practical application, '' and NUL mean two very different
>things, whether you're using SQL or not.
>
>
existing systems already work that way (make this distinction). But
still, you must agree that in practice this distinction isn't very useful...
Jonathan Neve.