> Not all are logged as negative, i collet (and pair) all yet logged: > > LOGEMU SQLITE3 > 3489577139 -> -805390157 If I run this in bash: $ echo $[0x100000000 - 3489577139] 805390157 It gives me the same number you get in SQLite. This means you are taking a number that needs 32-bits, and storing it in a place that only has 31 bits for storage. It is probably a signed 32-bit integer, which has 1 bit for sign and 31 bits for the number. If you switch to unsigned 32-bit integers, or 64-bit integers, you should be able to preserve your original figure. A quick Google suggests SQLite does this automatically. > I checked, that SQLite itself is not reason, i tried to cast 2605008384 > value to INT in sqlite3 shell tool and insert it into table without any > problems (in memory DB): > > sqlite> SELECT CAST(2605008384 as INT); > 2605008384 > > sqlite> CREATE TABLE test (val INT); > sqlite> INSERT INTO test VALUES (2605008384); > sqlite> SELECT * FROM test; > 2605008384 This means SQLite or your schema is not at fault, but rather whatever is handling the number before generating the SQL is using integers that are too small (or are incorrectly signed). Possibly it is something calling printf() and passing %ld instead of %lu for that field. Cheers, Adam.
