Obviously, that would mean losing all benefits of QtSql in the form of a RDBMS-neutral API and, as a consequence, [relatively] easy migration between backends.
To Martin: Are you sure the problem is caused by changes in Qt and not SQLite? Comparing "src/sql/drivers/sqlite/qsql_sqlite.cpp" on Gitorious shows that the QSQLiteDriver::open() method is pretty much the same in Qt4.8 and Qt5 — in Qt5 it has Q_D() and somewhat better error handling, nothing more. On 10/30/2013 04:51 PM, Konstantin Tokarev wrote: > 30.10.2013, 11:46, "Martin" <free...@rakor-net.de>: >> Hi there! >> >> I have a project written in Qt4.8 using the bundeled SQLite (Version >> 3.7.14.1). This program is running on multiple machines sharing the same >> sqlite-database. The program is for informational purposes and therefore >> with very few writing-access. This worked without issues all the time. (I >> know that it is not recommended to use a sqlite-file over a >> network-connection, but I need this). >> >> Now I am porting to Qt 5.1.1 and also using the bundeled SQLite (Version >> 3.7.17). The program runs without flaws, but as I start a second client it >> can not make any changes to the database getting the error “database is >> locked Unable to fetch row". It seems to me, that the first program using >> the database sets a database-wide lock until it is closed. So the first >> program opening the database has full access. Any program opening the >> database to a later point of time has only read-permissins. >> >> I tried to set the locking-mode PRAGMA to Normal (I know it should be at >> normal anyway). >> >> The problem remains when I use multiple clients on the same machine, using a >> local database-file (so it has nothing to do with network-filesystems >> locking features). >> >> I have started a thead on the forum >> https://qt-project.org/forums/viewthread/34130/#148660 and there I got the >> advice to send an email to this list. >> >> Asking in the sqlite-mailinglist I got this reply: >>> Sounds like something changed in Qt 5.1.1 so that it is holding open a read >>> transaction. The first process acquires the read transaction, which >>> permits other processes to read but prevents anybody else from writing. I >>> have no idea why Qt would do this, though. >>> […] >>> I think your goal should be to figure out why Qt 5.1.1 is holding open the >>> read transaction. >> >> So could you help with this issue? Was there any change in the way Qt >> handels SQLite-Databases? Could I somehow avoid this? > > You can use SQLite directly instead of relying on QtSql with SQLite plugin.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
