That's not strictly true, it depends on the threading mode: https://sqlite.org/threadsafe.html <https://sqlite.org/threadsafe.html>
It sounds like the driver is trying to manage concurrency on its own and failing. For the purposes of calling sqlite, if the library is used in the default "serialized" mode, then no locks at all should be necessary, but maybe the locks are required for something happening in the driver code. If you check which threading mode sqlite is running in you''ll either need to change the threading mode to serialized, and if that's already the case or changing to that doesn't fix it then the threading problem is in the driver code itself. > On Sep 25, 2017, at 11:33 AM, Clemens Ladisch <clem...@ladisch.de> wrote: > > Roberts, Barry (FINTL) wrote: >> The application is multi-threaded >> >> the system sometimes locks up, or marks one or more of the db3 as malformed. > > Sounds like a threading problem. > > You should not have more than one thread accessing the same connection > concurrently. > >> Using (connection) >> Open connection > > What is the relationship between threads and databases? Are you really > re-opening the connection for every transfer? > > > Regards, > Clemens > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
