On Sun, Nov 8, 2015 at 10:36 AM, Simon Slavin <slavins at bigfraud.org> wrote:
> > On 8 Nov 2015, at 4:11pm, John McKown <john.archie.mckown at gmail.com> > wrote: > > > I'm not a developer. So I guess that it's my ignorance as to why a > program > > would be confused by the string value of "null" or any variant thereof. > > NULL has a special meaning in SQL and some other database languages. > Depending on what the programmer wanted at the time it means something like > "Value unknown" or "No such value" or "Not applicable". All such programs > are meant to keep an extremely clear distinction between these two: > > surname = "Null" > surname = NULL > > But fast, lazy, untested programs, especially cases where a working setup > is moved to another language or another platform by someone who doesn't > understand picky details of the original tend to mess this up. Much more > often than you'd think. > > Many languages have documentation specifically on the problems of handling > NULLs. Here's part of SQLite's: > > <https://www.sqlite.org/nulls.html> > ?I am, at least somewhat, aware of the problems with NULL in SQL (and Java & C in which I "dabble"). I have read a number of Joe Celko's books. And have formed the opinion that NULLs are anathema from the problems that they introduce. But, then again, I do understand the need (i.e. a "person" record which records a birth date and a death date. What if the person is alive? What if you don't now the birth day?). ? -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown
