On 9/13/16, Eric Sink wrote:
> Excellent. Thanks.
Thanks for pointing out the issue. I have attempted to improve the
documentation here:
https://www.sqlite.org/wal.html#busy
Further improvements may be forthcoming.
--
D. Richard Hipp
d...@sqlite.org
Excellent. Thanks.
--
E
On Tue, Sep 13, 2016 at 3:05 PM, Richard Hipp wrote:
> On 9/13/16, Eric Sink wrote:
> >
> > I can fit this into your explanation:
> >
> > "Another process might have opened the same database with
> > locking_mode=EXCLUSIVE"
> >
>
On 9/13/16, Eric Sink wrote:
>
> I can fit this into your explanation:
>
> "Another process might have opened the same database with
> locking_mode=EXCLUSIVE"
>
> if I change the word "process" to "thread", and if I assume that
> sqlite3_open_v2() on a WAL-mode file can
The app had several threads that were frequently doing this:
open the sqlite file
do something
close it
When I changed it to stop opening the file so much and re-use the
connections, the problem went away.
I can fit this into your explanation:
"Another process might have opened the same
This is happening in an Android app. No other process is involved, but the
filesystem there is weird, so I'm focusing on the third possibility you
mentioned.
Thanks,
--
E
On Mon, Sep 12, 2016 at 7:52 PM, Richard Hipp wrote:
> On 9/12/16, Eric Sink
On 9/12/16, Eric Sink wrote:
> OK, this seems like a simple thing, but I'm stuck and looking for
> inspiration or clues.
>
> How can sqlite3_prepare_v2() return SQLITE_BUSY for a simple SELECT
> statement when in WAL mode?
>
> Immediately prior, a sqlite3_exec("BEGIN
6 matches
Mail list logo