[Qt-interest] QSQLITE and Network Shares
Bill King
bill.king at nokia.com
Mon Nov 16 23:59:54 CET 2009
On 11/17/2009 05:07 AM, ext Israel Brewster wrote:
>
> On Nov 15, 2009, at 2:13 PM, Bill King wrote:
>
>>>
>>>>
>>>>
>> The problem is an sqlite problem. What you are seeing is that another
>> query has a lock open on the table, and your query is trying to
>> elevate it's lock status.
>
> First off yes- PostgreSQL is a good option, and one I have
> implemented. I do agree that it is the way to go, however I also think
> that leaving something non-functional just because there is a better
> option is not acceptable. Of course, if this is a sqlite problem, then
> it's not your issue.
>
> That said, there are two serious flaws with your argument that this is
> an sqlite problem. First, there ISN'T another query that has a lock on
> the table. Look at the unit test I sent (with my first follow-up) - it
> creates a brand new database, opens it, and IMMEDIATELY tries to run a
> CREATE TABLE, getting this error (if on a network drive). The database
> hasn't even existed for more than a fraction of second. How and what
> could POSSIBLY have another query with a lock on the table, unless Qt
> itself put it there in the open command? Besides, the query I am
> running is a CREATE TABLE, so the table in question doesn't even exist
> when I run the query. How on earth could there be a lock on a table
> that doesn't exist? Actually, I get this error no matter the query I
> run, but using a CREATE TABLE query on a brand-new database precludes
> the possibility of a lock existing.
>
> Secondly, if I take Qt out of the equation, IT WORKS. Put Qt back into
> the equation, it doesn't work. Given that the only difference between
> the two tests was Qt (the test being create and open a brand-new
> database on a network share, and then run a CREATE TABLE query), how
> could this NOT be a Qt problem? I do apologize if I am being stubborn
> here, but saying it is a sqlite problem just doesn't fit the facts as
> I have presented them.
>
>>
>> Seriously, I would consider a proper client/server database system
>> rather than trying to get what is essentially a single user system to
>> act in a networked fashion.
>> There are lots of free/zero config databases out there. try
>> firebirdsql for instance, or postgresql, both have very permissive
>> licences, and cost you nothing.
>
> Agreed. That said, given that according to the official sqlite people
> this should work (and, in fact, does in testing once Qt is removed
> from the equation) doesn't it behoove you to make it work in Qt as well?
>> --
>> Bill King, Software Engineer
>> Qt Development Frameworks, Nokia Pty Ltd
>> Brisbane Office
>>
>> _______________________________________________
>> Qt-interest mailing list
>> Qt-interest at trolltech.com <mailto:Qt-interest at trolltech.com>
>> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
> -----------------------------------------------
> Israel Brewster
> Computer Support Technician II
> Frontier Flying Service Inc.
> 5245 Airport Industrial Rd
> Fairbanks, AK 99709
> (907) 450-7250 x293
> -----------------------------------------------
>
It does, and it will be tested in time. I'm still not convinced that
it's actually a qt issue, as we're not using sqlite in any funky fashion
(ie, we're using stock standard behaviour). However, If you can add a
bug report over at http://bugreports.qt.nokia.com/secure/Dashboard.jspa
I'll schedule it and put it onto the list :) Including the test app/ways
to reproduce is definitely most helpful. This way you can put a track on
it too, and it'll notify you when it's been handled.
--
Bill King, Software Engineer
Qt Development Frameworks, Nokia Pty Ltd
Brisbane Office
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20091117/fc971da6/attachment.html
More information about the Qt-interest-old
mailing list