Anomoly when storing empty values into SQLite integer fields
bobs at twft.com
Wed Feb 22 15:27:07 CST 2012
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.
On Feb 22, 2012, at 12:54 PM, Pete wrote:
> 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".
More information about the use-livecode