Anomoly when storing empty values into SQLite integer fields
pete at mollysrevenge.com
Wed Feb 22 18:53:15 CST 2012
Sorry but you're wrong on all counts. Read my earlier mails for info In
particular, LC is not retuning empty for a NULL value in an integer column
- it's returning zero, that's where this whole mess started!!! I am quite
happy for it to return empty for a NULL value but that's not what is
happening, at least for integer fields.
On Wed, Feb 22, 2012 at 1:27 PM, Bob Sneidar <bobs at twft.com> wrote:
> 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.
Molly's Revenge <http://www.mollysrevenge.com>
More information about the use-livecode