You can also use “BEGIN EXCLUSIVE” before any writes; this gets you a write transaction immediately. If this returns OK all following read/writes will not return BUSY.
A transaction can upgrade from a read only to a write (when you do a select followed by an insert). I think you get the snapshot error when the previous reads in the transaction no longer reference the HEAD database version because another connection has written to it. On Mon, 12 Aug 2019 at 11:03, Kira Backes <kira.bac...@nrwsoft.de> wrote: > > So how do you propose to have consistency and isolation if SELECT does > not create an automatic transaction if no explicit transaction exists? > > I think this is a misunderstanding which might explain your first > email reply. I do not propose any change for sqlite, but I wasted 2 > days debugging and reading every page in sqlite documentation (locks, > transactions, isolation, error description) did not help me. So I just > want the documentation to be improved. I would change the error > description for SQLITE_BUSY_SNAPSHOT so that it no longer says "read > transaction" but instead says "read transaction or ongoing select > statement". And the first sentence in "transactions" should be changed > to indicated that select statement also create implicit read > transactions. > _______________________________________________ > 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
