Teg wrote: > I'd like this clarified too. I specifically don't use transactions > when I'm selecting. In fact, I'll select, then start a transaction > later for inserting the results. Would I be better off wrapping the > whole thing in a transaction?
Cannot be sure without looking at your code/database schema/..., but it looks your usage pattern is wrong - there are race condition this way (that maybe alleviated by implicit transaction start by [unfinished] SELECT, but anyway it is fragile and wrong). > Wednesday, November 2, 2011, 9:13:20 AM, you wrote: > > BMI> Maybe my memory is fading but this is the first time I've heard > BMI> anybody say the wrapping a BEBIN around a SELECT was needed. I'd > BMI> swear it was always said it wasn't ever needed. BTW, what is "needed"? Nobody *force* you to use BEGIN/COMMIT around SELECT - transaction will be started (and ended) implicitly; just if you issue multiple statement, it is more efficient to take lock once, than take and release lock (and lot more - check database schema, flush cache, etc) for each statement. And, of course, if you need consistent database state across many sql statements, you need to wrap all of them in single transaction. >> >From the docs > > BMI> http://www.sqlite.org/lang_transaction.html > > BMI> basically, any SQL command other than > BMI> SELECT<http://www.sqlite.org/lang_select.html>) will > BMI> automatically start a transaction if one is not already in effect > > > > BMI> Now you're saying SELECT always starts a transaction? PS A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
