I'm using SQLite to store some data. The primary database is on a NAS (Debian Lenny, 2.6.15, armv4l) since the NAS runs a script which updates the data every day. A typical "select * from tableX" looks like this:
2010-12-28|20|62.09|25170.0
2010-12-28|21|49.28|23305.7
2010-12-28|22|48.51|22051.1
2010-12-28|23|47.17|21809.9
When I copy the DB to my main computer (Mac OS X) and run the same SQL query, the output is:
2010-12-28|20|1.08115035175016e-160|25170.0
2010-12-28|21|2.39343503830763e-259|-9.25596535779558e+61
2010-12-28|22|-1.02951149572792e-86|1.90359837597183e+185
2010-12-28|23|-1.10707273937033e-234|-2.35343828462275e-185
The 3rd and 4th column have the type REAL. Interesting fact: When the numbers are integer (i.e. they end with ".0"), there is no difference between the two databases. In all other cases, the differences are ... hm ... surprising? I can't seem to find a pattern.
If someone's got a clue - please share!
PS: sqlite3 -version output Debian: 3.6.21 (lenny-backports) Mac OS X: 3.6.12 (10.6)
High write volumes: SQLite allows only one write operation to take place at any given time, which significantly limits its throughput. If your application requires lots of write operations or multiple concurrent writers, SQLite may not be adequate for your needs.
uses SQLite in their Android cell-phone operating system, and in the Chrome Web Browser. Intuit apparently uses SQLite in QuickBooks and in TurboTax to judge from some error reports from users seen here and here.
Because of its flexibility and platform independency it is widely used. It contains simple data types, having dynamic querying capability. Keywords: SQLite, database, multiplatform, android, platform independent.
SQLite databases are portable across 32-bit and 64-bit machines and between big-endian and little-endian architectures. The SQLite database file format is also stable. All releases of SQLite version 3 can read and write database files created by the very first SQLite 3 release (version 3.0.
In release 3.4.0 of SQLite there was a compile time flag added.
- Added the SQLITE_MIXED_ENDIAN_64BIT_FLOAT compile-time option to support ARM7 processors with goofy endianness.
I was having this same problem with an Arm920Tid device and my x86 based VM. The arm device was writing the data, and I was trying to read it on the x86 VM (or on my Mac).
After adding this compile time flag to my makefile for my arm build I was able to get sane values when I queried the DB on either platform.
For reference I am using sqlite 3.7.14
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With