Anomoly when storing empty values into SQLite integer fields

[Bob Sneidar]

Ok. But if it really were the string value "NULL" that gets saved to the database, wouldn't you get "NULL" in your select statement?? Try using a lowercase null in your update statement, then view the sqLite table with a utility to see what it says the value is. If it's capital NULL it is actually the NULL character. 

LC is not going to reinterpret a string value as empty just because the word "NULL" was what the value was. This seems to indicate that the update command actually DID save the NULL properly. As for a select statement returning empty string for a NULL value, this was discussed some time ago when I was first getting into database access from LC. The idea is that LC never wanted to return an ASCII 0 character in ANY string because it tended to wreak havoc with displaying text in fields and other objects. I believe that an empty string is precicely what the RunRev people WANT to return for a NULL value. 

Sorry, I don't mean to sound argumentative, but it "seems" to me that it is doing what it was at least designed to do. 

Bob


On Feb 22, 2012, at 12:54 PM, Pete wrote:

> Bob,
> Check back in my earlier emails on this thread.  As you experienced,
> specifying NULL with no quotes results in the literal string "NULL" going
> into the column which is totally wrong.  NULL means "no value", not empty
> nor the literal value "NULL".  Just to confuse things even more, when you
> read that value back with a SELECT, LC does treat "NULL" as meaning no
> value instead of the literal value "NULL".