Re: NULL versus empty string

"Tim" <nocomment_at_rogers.com> wrote in message news:3D8FB9B7.7090602_at_rogers.com...
> I would guess that the logic is that if you don't want to allow null,
> then you want an actual value and "" while not being null, is not really
> a value conceptually. I mean, if "" was acceptable, why not just allow
null?

It would be nice if a zero length string were treated like a zero length string instead of a non-existent string. When a string is null, it often can be used as a flag to tell me whether the user needs to set the field or not (for example, on initialization, when most fields are blank for a customer record, I prompt them specifically for the null fields since that means they've not even elected to set them; however, if they then choose to set it, and perhaps clear it later, I don't want to treat it as if they have never set the string, only that they've elected to have it be empty). Empty strings just aren't the same as no string at all. They are distinct in programming.

While I agree at the most basic level, the issue has to do with programming, especially via JDBC (so I'd guess it's similar for ODBC). In those APIs, to set a value to null, you use a special method: statement.setNull(col,type). When a null comes back in, you are supposed to detect this with resultSet.getString(col); if ( resultSet.wasNull() )...

You can append a string to another string, but you cannot append a string to a null. If a null string is dereferenced (in Java, C, C++), you get an exception, but you don't with an empty string.

So, while I agree that if the column is not truly required, then null should be allowed. If I do this, unfortunately, it breaks JDBC code (or makes it substantially more painful to deal with) because now both a real null string and an empty string are treated by the database the same way, yet they are distinct within the code.

David Received on Mon Sep 23 2002 - 20:53:04 CDT