Dear Igor, Andy, Keith
Thank you for your patience to explain. Now very clear to me why it is not
worth for the second process to honor the sqlite_busy handler, and instead
returns immediately. In retrospect re-reading with your explanations in mind, I
also understand the official documentation
On Saturday, 22 February, 2020 09:26, Andy Bennett
wrote:
>This other process has called "BEGIN IMMEDIATE TRANSACTION" and
>https://sqlite.org/rescode.html#busy says
>"The BEGIN IMMEDIATE command might itself return SQLITE_BUSY, but if it
>succeeds, then SQLite guarantees that no subsequent op
Hi,
A busy_timout is honored by write commands outside of
transactions and by single write commands inside transactions,
but not if preceded by a read command. I did not find this
behaviour in the documentation, thus it might be a bug.
It's documented in the description of sqlite3_busy_handl
On 2/22/2020 7:50 AM, softw...@quantentunnel.de wrote:
A busy_timout is honored by write commands outside of transactions and by
single write commands inside transactions, but not if preceded by a read
command. I did not find this behaviour in the documentation, thus it might be a
bug.
It's
Hi
A busy_timout is honored by write commands outside of transactions and by
single write commands inside transactions, but not if preceded by a read
command. I did not find this behaviour in the documentation, thus it might be a
bug.
To reproduce (in a linux terminal):
sqlite3 ~/test.db "C
5 matches
Mail list logo