Thank you Rowan, in the context of *locks* it is kinda documented, but not in the context of transactions :(
Just have a look at the error description: https://www.sqlite.org/rescode.html#busy_snapshot > The SQLITE_BUSY_SNAPSHOT error code is an extended error code for SQLITE_BUSY > that occurs on WAL mode databases when a database connection tries to promote > a read transaction into a write transaction but finds that another database > connection has already written to the database and thus invalidated prior > reads. > > The following scenario illustrates how an SQLITE_BUSY_SNAPSHOT error might > arise: > > Process A starts a read transaction on the database and does one or more > SELECT statement. Process A keeps the transaction open. > Process B updates the database, changing values previous read by process A. > Process A now tries to write to the database. But process A's view of the > database content is now obsolete because process B has modified the database > file after process A read from it. Hence process A gets an > SQLITE_BUSY_SNAPSHOT error. in my opinion and from what I've read I've never started a READ transaction. And if I open the transaction documentation it explicitly says that SELECT statements to not start a read transaction. This is a different concept from a SHARED lock. If it isn't than it should be clearly explained and documented that every SHARED lock = READ transaction. mit freundlichen Grüßen, Kira Backes _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
