Definately use 3.5.4. Not sure how to determine at compile time if the threadsafe part is enabled. You can always compile yourself to guarantee its set, thats what I do.
sqlite will lock the database file for you automatically. Your threads do not need to implement locking. But they do need to handle in some fashion. SQLITE_BUSY and/or SQLITE_LOCKED error codes. You should also look at "Begin", "Begin Exlusive" and "Begin Immediate" sql commands. As a user you don't get to pick the lock state, sqlite does that automatically for you. You must handle the return codes suche as SQLITE_BUSY, SQLITE_LOCKED etc. I don't have any simple examples available, sorry. Ken Andreas Volz <[EMAIL PROTECTED]> wrote: Am Wed, 9 Jan 2008 09:03:35 -0800 (PST) schrieb Ken: > Andears, > > SQLITE 3.5.x is thread safe when configured and compiled with > --enable-threadsafe. I've only 3.4.1 installed. But Gentoo has 3.5.4 in the unstable tree. I'll install that one if needed. And is it possible to find out at compile time (or runtime) if sqlite was compiled with treadsave? > You can create multiple db connections to a single database. > > But only one connection will be allowed to write to the Database at a > time. > > Take a look at > http://www.sqlite.org/lockingv3.html > http://www.sqlite.org/34to35.html (section 2.1.5 part about locking) Thanks for the links. I think the PENDING state should be the correct one for my application. But not sure if I understand it correct. So my threads could read and write without locking. Sqlite does then execute the write if a lock is available. So I don't have to trouble about locking. Is this correct? Are there any examples for sqlite multi-threading access? regards Andreas ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
