[Qt-interest] [SOLVED] QSqlQuery caching INSERT data?

Bill King bill.king at nokia.com
Tue Nov 24 00:11:26 CET 2009


On 11/24/2009 08:35 AM, ext Israel Brewster wrote:
>
> On Nov 22, 2009, at 3:19 PM, Bill King wrote:
>
>> Yeah, again this is an sqlite issue. Sqlite if I remember correctly
>> won't close the transaction until you release the read lock (ie close
>> the select query). Its locking semantics are frustrating at the best
>> of times... ;)
>
> You're telling me. At least I have everything working right now :-) So
> is Qt using transactions behind the scenes then? Or is it that SQLite
> considers each query a "transaction", even if you haven't explicitly
> started one?
The second. (to repeat what you said) If you don't explicitly start a
transaction, sqlite wraps the statement up in one, and auto-commits it
when it closes.
>
> Out of curiosity, why didn't calling close on the database properly
> close out the select? The behavior I was seeing implied that until I
> either a) explicitly called finish() or b) the query went out of
> scope, the read lock remained open, preventing new data from being
> written to disk. I would have thought that calling close() on the
> database would have finish()'d any active SELECTS as well, but that
> doesn't appear to be the case. Thanks for putting up with me as I
> struggled through this stuff :)
Not sure on the select not closing. I'm a bit on the busy side right at
this minute getting some preparatory research done for some ORM/QML
stuff, but if you can create a bug for me @ bugreports with a repeatable
recipe, and I'll look at it when I've got 10 minutes/add a new autotest
to check it doesn't happen again.

-- 
Bill King, Software Engineer
Qt Development Frameworks, Nokia Pty Ltd
Brisbane Office




More information about the Qt-interest-old mailing list