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

Reply via email to