I have two versions of this; this being a set of tables for tracking options. Version 2 uses auto incrementing keys, and does slightly different operations when setting values, Version 4 uses GUID keys, so every value is created before inserting, and I don't need last_insert_id() sort of thing.
Although, they both seem to be using the database connections correctly On one, I do insert, insert, replace into, delete; the other just does inserts with no deletes in the transaction. The one that includes doing a delete is deadlocking. I'll see if I can make a test case On Wed, Jun 19, 2013 at 1:58 PM, J Decker <[email protected]> wrote: > I have a sqlite database that ends up with 3 connections from the same > program in a single thread. The first, only SELECT statements are > used. The second, is opened, a BEGIN TRANSACTION issued and then some > inserts. I end up opening a 3rd connection to the database and issue > another begin transaction and start more inserts. > > The insert on the 3rd connection is blocked 'SQLITE_BUSY'. > After 1 second, a COMMIT on the 1st connection is issued, and stays > blocked with 'SQLITE_BUSY'. > > so then the program alternates retrying the last commands since busy > is supposed to be temporary. > > COMMIT - busy > insert - busy > commit - busy > insert - busy > > The 3rd connection's insert is into a table that has been inserted > into by the 2nd connection. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
