If the sqlite statement had a temporary storage area so that I could load up a bunch of rows and then commit them in one shot so that the lock on the db was not held very long by a single transaction, that would probably work.
However, my reading of the documentation leads me to believe that using the bind functions in a loop with an insert statement will lock the entire in-memory DB until the bulk insert is done....which means I would get no benefit from concurrency. Is this correct? BTW: does the question I posed on modifying the library to add a feature to attach an in-memory data stores to another one via the C API belong on the sqlite-dev list? thanks, James On Apr 18, 2008, at 9:43 :22AM, John Stanton wrote: > Just use a thread as a DB handler. Queue transactions to it using > some > IPC mechanism like a message queue or named pipe. Another way would > be > to synchronize access to the DB handle using a mutex. > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
