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". _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
