On May 4, 2009, at 2:38 PM, Christopher Taylor wrote: >> I am told that SQLite compiles and runs out-of-the-box on Integrity >> OS. No porting necessary. But not having a license for Integrity OS >> nor hardware to run it on, I've never actually tried this myself. > > Thanks for a quick response. I will try and be more precise. > > I get a number of unresolved symbols with the stock files. I have > downloaded 3.6.13 and am compiling with the sqlite3.c and sqlite3.h > files > into a library. There are several pthread related symbols and dlopen, > dlerror, dlclose, and dlsym. > > The pthreads look to have something to do with this not being a unix > based > os which it is defaulting to. I set threadsafe to 0 to resolve > this. I am > putting all db code within one library with its own mutex and do not > feel > the threading will be an issue. > > The dl symbols are for loading libraries. I have defined > SQLITE_OMIT_LOAD_EXTENSION. This removed those unresolved symbols.
The previous two paragraphs are how I was going to suggest you fix the compile problem. With those changes, everything should work fine. > > > As for my code, the log table is queried once a second with a max of > 200 > records returned and a min of 0. A timer is putting one new record > in the > table every 5 seconds. A trigger after the insert is making sure > that the > table does not exceed 5000 records. > > Prior to this I had a circular file with 1000 records. This never > exhibited > any problems running the same test. > SQLite insists on making sure that that your data really is on nonvolatile media (flash in your case) before it finishes the transaction. That way, if you lose power unexpectedly, your data does not go corrupt due to a partial write. But flash is slow and waiting for a write of flash memory to complete can take a long time. So you have a performance vs. data security tradeoff. If you don't want to wait, set "PRAGMA synchronous=OFF". Then it will return quickly and your OS will continue doing the write in the background. But if you lose power when the database is half-way written, well, in that case I hope you have a backup copy. (The new sqlite3_backup interface might help there, btw.) Another trick is to write your updates into a TEMP table (which is not synced to disk) and then modify your queries to pull data out of both the main table and the TEMP table. Then, periodically, flush the TEMP table to disk in a single transaction. If you lose power, you've only lost the changes since the last flush. And everything is guaranteed to stay consistent. D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
