On 29 Sep 2016, at 8:39am, Jim Borden <jim.bor...@couchbase.com> wrote:
> I found the following snippet from https://www.sqlite.org/lockingv3.html > > ➢ The SQL command "COMMIT" does not actually commit the changes to disk. It > just turns autocommit back on. Then, at the conclusion of the command, the > regular autocommit logic takes over and causes the actual commit to disk to > occur. > > Does that mean that the actual commit happens after the execution of “COMMIT” > (i.e. it is in a sense asynchronous)? No. It happens before the API call you're doing finishes. Remember that the SQLite library is just a collection of procedures which you run inside your program. SQLite does not run in a different thread or on a different computer while your program does its own thing. > I have two connections to a database file and reports that writing to one > and then immediately querying from another causes the second connection to > show the entry as missing. Are you using multiple processes or threads ? Are you using any PRAGMAs which look like they might speed up SQLite operations ? Are the two connections accessing the file using identical file specifications ? Are you forgetting to finalize a _prepare,_step,_finalize sequence ? Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users