Re: [sqlite] Lock before beginning SELECT statement

On 15 Apr 2014, at 1:47pm, MikeD wrote: > If another thread deletes/updates or inserts while a SELECT statement is > processing the results could > be unpredictable? Only if your timing is unpredictable. If you know which command is issued first, you know what the results will be. > Would is

Re: [sqlite] Lock before beginning SELECT statement

On 4/15/2014 8:47 AM, MikeD wrote: If another thread deletes/updates or inserts while a SELECT statement is processing the results could be unpredictable? Is that other thread using the same connection as the SELECT, or a different connection? If the latter (two separate connections), than the

Re: [sqlite] Lock before beginning SELECT statement

Is this true? A SELECT statement acquires a SHARED lock which block writers anyway. Source: http://sqlite.1065341.n5.nabble.com/Multiple-SELECTs-and-single-SELECT-and-TRANSACTION-td12752.html -- View this message in context: http://sqlite.1065341.n5.nabble.com/TRANSACTIONs-tp23854p75091.html

[sqlite] Lock before beginning SELECT statement

If another thread deletes/updates or inserts while a SELECT statement is processing the results could be unpredictable? Would issuing a BEGIN IMMEDIATE before a SELECT statement solve this? -- View this message in context: http://sqlite.1065341.n5.nabble.com/TRANSACTIONs-tp23854p75089.html

Re: [sqlite] Lock before beginning SELECT statement

SELECT automatically handles locking? https://www.sqlite.org/lockingv3.html If multiple commands are being executed against the same SQLite database connection at the same time, the autocommit is deferred until the very last command completes. For example, if a SELECT statement is being executed