[SOLVED] QSqlDatabase annoying warnings
I have the following bit of code:
- class zzzz
- QSqlDatabase m_database;
- m_database= QSqlDatabase::addDatabase("QSQLITE");
Whenever this runs, I get hit with the following lines on my console:
QSqlDatabasePrivate::removeDatabase: connection ‘qt_sql_default_connection’ is still in use, all queries will cease to work.
QSqlDatabasePrivate::addDatabase: duplicate connection name ‘qt_sql_default_connection’, old connection removed.
Is there any way to get rid of these complaints? Or better yet, can someone tell me how to do this correctly? I’m obviously missing something here..
Oh dear, looks like I messed up…
I can’t very well post the actual code, since that belongs to a customer. I thought the stripped out bits I did post were enough to reproduce the issue, but the quick and dirty version I just put together at home does not show the problem. I’ll start stripping down the real code until the bare minimum to show the problem remains when I get back to the office tomorrow. I’ll post further updates when I have a complete minimal example.
If you call function() more than once without cleanly calling QSqlDatabase::removeDatabase() in between then you will get this warning. To cleanly close the database:
You will have difficulty because you are holding m_database as a member variable and it cannot be out-of-scope. I find it easier to fetch a local handle handle using QSqlDatabase::database() in routines that need it and never holding a handle for a long period.
On the other hand, you may be calling QSqlDatabase::addDatabase() when you really want QSqlDatabase::database() to get a handle to an existing database for use inside function().
Thank you all for the responses, and just as importantly, for providing a forum where asking for help forced me to to take a new, hard look at all the code to be able to explain the problem.
It turns out somewhere else in the code there was also a call to QSqlDatabase::addDatabase(“QSQLITE”), which had escaped my notice the first times round. This second call should not have been there in the first place, and eliminating it solved this issue. In retrospect, the runtime system was entirely correct in complaining as it did (no surprise, really..).