I have no idea why it doesn't work in that way, it used to in my application. however, just a few points:
maybe your BEGIN wasn't successful and you didn't realize ? maybe you run the INSERT on a DB handle that was not the one that invoked the BEGIN ? maybe your COMMIT wasn't successful and you didn't realize ? maybe your are not in threadsave mode ? I suggest that you post at least a part of your code here, or even better a short example that shows the problem. This usually gives the people here a better chance to provide useful hints. hope this helps Marcus > Hi, Dave > > I have read your post. I have also read many of the recent archived posts, > and googled the web for hints. I'm at a loss here. > > The fun thing is that my wrapper class (which I use for a while now in > non-MT environments) allows me to track most of what's going on in SQLite. > And even that does not help. > > My protocol shows (for the same thread!) > > BEGIN EXCLUSIVE TRANSACTION > INSERT... > COMMIT > > BEGIN EXCLUSIVE TRANSACTION > INSERT > < and here it blocks for ever > > > > I wonder why the INSERT blocks after the BEGIN is through, and why it > works > for the first sequence. > From what I can tell, all other threads as suspended, have their > statements > properly reset or finalized etc. Since I use wrappers for statements etc. > they all clean up proper after themselves. > > I would wish I could somehow see _why_ and _where_ SQLite is blocking a > connection. > > I'm hoping that somebody here on the list comes up with a tip :-) > > > -----Original Message----- > > Wow this sounds exactly like my post of a few days ago titled "Strange > sqlite_busy deadlock behavior". > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
