Re: [sqlite] Begin immediate transaction -> SQLITE_BUSY (database is locked)

On 10/18/2012 09:05 PM, Pavel Ivanov wrote: On Thu, Oct 18, 2012 at 6:32 AM, Daniel Polski wrote: The SELECT statement, including the _prepare() stage and all the _step()s until you've reached the last row, and then the _finalize(), is all one process. They're all part

Re: [sqlite] Begin immediate transaction -> SQLITE_BUSY (database is locked)

On Thu, Oct 18, 2012 at 6:32 AM, Daniel Polski wrote: >> The SELECT statement, including the _prepare() stage and all the _step()s >> until you've reached the last row, and then the _finalize(), is all one >> process. They're all part of the statement and you can assume

Re: [sqlite] Begin immediate transaction -> SQLITE_BUSY (database is locked)

On 18 Oct 2012, at 2:32pm, Daniel Polski wrote: > I logically do understand that there can't be 2 writers updating the database > at the same time, but I don't understand why the second insert statement in > the example below won't work without finalizing the SELECT

Re: [sqlite] Begin immediate transaction -> SQLITE_BUSY (database is locked)

The SELECT statement, including the _prepare() stage and all the _step()s until you've reached the last row, and then the _finalize(), is all one process. They're all part of the statement and you can assume that the database is still locked until you do a _finalize(). If you are using the

Re: [sqlite] Begin immediate transaction -> SQLITE_BUSY (database is locked)

On 18 Oct 2012, at 10:55am, Daniel Polski wrote: > What if I create the SELECT sqlite3_stmt and want to step through the data to > evalute if an insert is needed? > If I find a matching row and create another sqlite3_stmt (INSERT) it will > convert the SELECT statement

Re: [sqlite] Begin immediate transaction -> SQLITE_BUSY (database is locked)

Pavel Ivanov skrev 2012-10-17 16:08: The problem is you are starting read-only transaction by executing SELECT and then try to convert this transaction into writing one by executing BEGIN IMMEDIATE. If in such situation SQLITE_BUSY is returned you have to finish the transaction and start it

Re: [sqlite] Begin immediate transaction -> SQLITE_BUSY (database is locked)

The problem is you are starting read-only transaction by executing SELECT and then try to convert this transaction into writing one by executing BEGIN IMMEDIATE. If in such situation SQLITE_BUSY is returned you have to finish the transaction and start it again. In your code solution is easy:

Re: [sqlite] Begin immediate transaction -> SQLITE_BUSY (database is locked)

Hello again, Attached is a test application which replicates the problem. I expected the transactions to block each other exactly like they do in the beginning (one connection successfully begins and the other receives SQLITE_BUSY), but I didn't expect the blocked connection to never get

Re: [sqlite] Begin immediate transaction -> SQLITE_BUSY (database is locked)

One of the other threads is writing at the same time. SQLite only allows a single writer at a time to a single database file. Others have to wait in line. Your solution is that when you get an SQLITE_BUSY, delay for a short while and then try again. Keep trying until you break through. Note

Re: [sqlite] Begin immediate transaction -> SQLITE_BUSY (database is locked)

On Tue, Oct 16, 2012 at 4:33 AM, Daniel Polski wrote: > > Hello, > I have a hard time finding the cause of a bug in my application. I believe > that it's me doing something wrong and not sqlite since I can't reproduce > the error in a simple example. I have 4 threads

Re: [sqlite] Begin immediate transaction -> SQLITE_BUSY (database is locked)

Nothing obvious springs to mind but I do see that you are not checking the values returned by most of your sqlite_exec() calls. Perhaps you could write a little routine that does the sqlite_exec() and then asserts that the value returned is SQLITE_OK. It may be that it's actually one of the

Re: [sqlite] Begin immediate transaction -> SQLITE_BUSY (database is locked)

On 16 Oct 2012, at 9:33am, Daniel Polski wrote: > What confuses me is that the "BEGIN IMMEDIATE TRANSACTION" sometimes fails > with a SQLITE_BUSY[5] (database is locked) after some iterations in the loop > even though all previous actions so far has returned SQLITE_OK.

[sqlite] Begin immediate transaction -> SQLITE_BUSY (database is locked)

Hello, I have a hard time finding the cause of a bug in my application. I believe that it's me doing something wrong and not sqlite since I can't reproduce the error in a simple example. I have 4 threads mostly reading data from a database, and all threads open "own" database connections.