Jens Alfke-2 wrote > But since the connections are sharing a cache, they still end up seeing > uncommitted writes.
I believe this is managed by the read_uncommitted pragma <https://www.sqlite.org/pragma.html#pragma_read_uncommitted> . Another interesting distinction between shared and private cache mode I found while experimenting. Ordinarily if connection A is in the middle of fetching result rows from a SELECT (i.e., sqlite3_step was called, but not sqlite3_reset), and connection B tries to do a CREATE/UPDATE/DELETE, B will get back SQLITE_BUSY. However, with a shared cache, B's operation will immediately succeed, provided it doesn't affect the same table(s). -- Sent from: http://sqlite.1065341.n5.nabble.com/ _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
