Re: [sqlite] [EXTERNAL] Re: sqlite3_stmt limitations

2017-09-21 Thread R Smith
On Wed, Sep 20, 2017 at 1:41 PM, heribert wrote: Do i have to open a database connection for each threat? Only if you work at the NSA. (It's the answer everyone else wanted to post, but maturely refrained from doing... I was weak, sorry!)

Re: [sqlite] [EXTERNAL] Re: sqlite3_stmt limitations

2017-09-20 Thread Dominique Devienne
On Wed, Sep 20, 2017 at 1:41 PM, heribert wrote: > Do i have to open a database connection for each threat? Like > > rc = sqlite3_open("file::memory:?cache=shared", ); I believe so, yes. --DD PS: See also this thread:

Re: [sqlite] [EXTERNAL] Re: sqlite3_stmt limitations

2017-09-20 Thread heribert
Do i have to open a database connection for each threat? Like rc = sqlite3_open("file::memory:?cache=shared", ); Am 20.09.2017 um 09:16 schrieb Hick Gunter: Make sure each thread has ist own private connection to the SQLite database (see https://sqlite.org/inmemorydb.html) Prepare the

Re: [sqlite] [EXTERNAL] Re: sqlite3_stmt limitations

2017-09-20 Thread Hick Gunter
SQLite will block access to the whole database during a write operation. Readers will have to wait until the write completes, even if the object they are interested in is not affected by updates. Protecting each object's data with a posix read-write lock will allow readers to access any object

Re: [sqlite] [EXTERNAL] Re: sqlite3_stmt limitations

2017-09-20 Thread Hick Gunter
Make sure each thread has ist own private connection to the SQLite database (see https://sqlite.org/inmemorydb.html) Prepare the statement once in each reader thread and use the bind functions to set the constraint values The writer thread will need to prepare statements to populate the db