[EMAIL PROTECTED] wrote: > I've been playing around with using SQLite for a data store in a newsreader > app for a few days now, and I keep getting the database stuck in a locked > state. The only thing that seems to fix it is deleting the file and starting > over.
Shutting down your process (with "kill -9" or the equivalent) should always unlock the database file. If you are finding that it doesn't, that means your system might not be obeying POSIX semantics or there is some other process you don't know about that is still running and is holding the lock or somethingn like that. You didn't mention what operating system you are working on.
> I tried recompiling with -DTHREADSAFE=1, but it didn't seem to make any > difference. Since I'm debugging, I'm crashing a lot before I have a chance > to sqlite_close() the database. Is that the problem? If it is, is there any > way to unwedge a database if the app crashes before closing it?
Failure to call sqlite_close() will NOT leave a database locked or in an inconsistent state. SQLite is designed to handle program crashes (and operating system crashes and power failures) gracefully. The worst that can happen is that the next time you open the database, your uncommitted changes will get rolled back. Crashing programs or power failures should NEVER cause database corruption.
> > I'm trying to access the database from two threads: the UI thread mostly > reads and occasionally updates rows, while the network thread loads new > messages and inserts them. Will that work, or do I just misunderstand how > SQLite does multithreading? >
Each thread should do its own sqlite_open() and they should not share the sqlite* pointers that their respective sqlite_open() calls return.
-- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
