There's no need for any global objects all the more if you only have one active connection for your application but it's also valid if you are managing multiple connections. The QSqlDatabase class already provides everything you need.
Like written in the documentation, if you are only using one connection, don't give it a name, it will become the default connection and all the SQL related classes will use it by default.
If you have several connections, it's easy to retrieve the one you are interested in by using QSqlDatabase::database.
On a side note, you should properly test the outcome of your open call. Right now it could be failing and you don't care about that possibility.
Well its used with all QWidgets so would make sense.
Its something to be aware of when creating GUI and also the little note that
any QWidget that are not given a owner/parent, will become a window.
That can be surprised when coming from other frameworks.
Say you make a new label
QLabel *lab= new QLabel();
Since its given no parent, it will become a window.
That was pretty surprising to me first time as i wanted to insert it into the main window.
The following SQL, with the Chinook test database open will create a new file in the same directory named 'out.sqlite' holding all of the album information for artist 51 with the original table layout.
A Qt model is totally unnecessary. Just run the query and it will create your file. From there you can compress it and ship it.
ATTACH DATABASE 'out.sqlite' AS outdb;
CREATE TABLE outdb.album
SELECT * from album
WHERE ArtistId = 51;
DETACH DATABASE outdb;
It does use SQLite specific sql.
Note especially that the ATTACH DATABASE and DETACH DATABASE are sql to be sent to the database just like the CREATE TABLE..
BTW, I have never done this using Qt, only in batch files, but I see no reason for it not to work both ways.
thanks for your help, I have tried to edit my odbc.ini the Mac refused to save the file... That's why I gave up.
As an intern, it's my tutor training who said to me to look at a native component. But if I can't find any solution I will come back to the first idea :)
@Paul-Colby you are correct. I should not program after 11 :)
The error is still persisting after the change though. That is because of an extra parenthesis at (glb_expiresat BETWEEN (:expiryFrom1 AND :expiryTo1)