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 again. In
your code solution is easy: finalize SELECT statement before executing
BEGIN IMMEDIATE.
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 to a write transaction? ...Which would
make all other threads unable continue without restarting "from the
top"? (No need to continue search through their SELECT statements if
they cannot begin an INSERT transaction anyway).
From what I understand you mean this is what happens (I don't think I
understood correctly though):
1. Connection A creates a read statement for table2, table3.
2. Connection B creates a read statement for table2, table3.
3. Connection A steps through the data and creates a write statement to
begin->insert->commit data to table1, success. (This also changes
Connection A's read in step 1 to a write statement.)
4. Connection B steps through the data and tries to begin, fails since
it can't convert the read at step 2 to a write transaction since
Connection A's statement in step 1 now is a write transaction?
Why does it try to convert the read transaction (table2, table3) to a
write transaction when another prepared statment inserts data to an
unrelated table (table1)?
Best Regards,
Daniel
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
