Ken wrote:
I think the issue however was that sqlite uses Signed integers And my Number although a valid 64bit hex number was to large to fit into a 64 bit signed value.
Yes, that's what I said. :-)
Sqlite simply coerced it into a "text" field for storage.
No, SQLite converted in to a floating point numeric value. The trace below shows what happens when inserting these values. sqlite> create table t(a); sqlite> insert into t values (18446744073709486080); sqlite> select typeof(a) from t; real sqlite> select a from t; 1.84467440737095e+19 sqlite> insert into t values (-1 << 16); sqlite> select typeof(a) from t; real integer sqlite> select a from t; 1.84467440737095e+19 -65536
In the mean time I wonder if it would be possible as an enhancement to add 64bit unsigned integer storage into sqlite? And also the capability to convert strings such as '0xffff' as this would make writing this typeof bit based logic so much easier.
I doubt if you will ever see unsigned 64 bit integer support in SQLite. The range of valid integer values is -9223372036854775808 to +9223372036854775807. I believe Richard Hipp thinks one integer type is already one too many. :-)
I can see the usefulness of the hex literals for integers in some applications, but I doubt it will be seen as common enough to warrant adding it to the language. You can always convert the hex to decimal outside SQLite and insert the decimal literal along with the corresponding hex value in a comment, or you can generate the required values when needed as I have suggested.
As always you should check if you are using the right tool for the job. SQL isn't really intended for bit field manipulations. It can be done, but perhaps it should be done elsewhere.
HTH Dennis Cote ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
