MySQL connection setup with diffent behaviour on deployed machine

Marble2Go

I have wriiten a simple Qt application to test the connection to a MySQL database. I have successfully compiled the qsqlmysql.dll driver as decribed in the documentation. I was able to connect to the MySQL database on my host development machine (PC with Microsoft Windows 10 x64 (20H1) Professional using Qt 5.13.2, Microsoft Visual Studio 2019 Build Tools, Windows 10 2004 SDK).
After that I deployed the "release" folder containing the files and folders:

sqldrivers
libmysql.dll
qsqlmysql.dll
QtCode.dll
QtSql.dll
dbBasic.exe

I deployed it on a virtual machine with Microsoft Windows 10 x64 (1809). On the VM was also a MySQL Server with the same configuration running, but here I got the error message:

QSqlDatabase: QMYSQL driver not loaded
QSqlDatabase: available drivers:
QSqlDatabase: an instance of QCoreApplication is required for loading driver plugins
QSqlError("", "Driver not loaded", "Driver not loaded")

Okay, the simple solution was to add the line

QCoreApplication app(argc, argv);

at the beginning of the simple Qt application. After a new compilation and deployment the program also ran on the deployment VM, but that is not the problem and question.
The question is rather why it worked on my host PC without adding the mentioned line of code?

Here is the source code of the simple Qt programm (main.cpp):

#include <QtSql>
#include <QDebug>

int main(int argc, char *argv[])
{
  // Setup db connection
  QSqlDatabase db_conn =
      QSqlDatabase::addDatabase("QMYSQL", "contact_db");

  db_conn.setHostName("127.0.0.1");
  db_conn.setDatabaseName("contact_db");
  db_conn.setUserName("root");
  db_conn.setPassword("<passord>");
  db_conn.setPort(3306);

  // Error checks
  if (!db_conn.open())
  {
    qDebug() << db_conn.lastError();
    return 1;
  }

  // Here comes some other code ...
}

I used the following PRO file:

TEMPLATE = app
TARGET = dbBasics
INCLUDEPATH += .
INCLUDEPATH += "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.27.29110\include"
INCLUDEPATH += "C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt"
INCLUDEPATH += "C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\um"
INCLUDEPATH += "C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\shared"
INCLUDEPATH += "C:\Program Files\Tools\Qt5.13.2\5.13.2\msvc2017_64\include\QtWidgets"
LIBPATH += "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\um\x64"
LIBPATH += "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\ucrt\x64"
LIBPATH += "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.27.29110\lib\x64"

QT += sql 
CONFIG += console

DEFINES += QT_DEPRECATED_WARNINGS

SOURCES += main.cpp

Any ideas?

JonB

@Marble2Go said in MySQL connection setup with diffent bevaiour on deployed machine:

The question is rather why it worked on my host PC without adding the mentioned line of code?

It ought not to have done so.

You should/must always create a Qt application before using anything like a QSqlDatabase. I don't know if anyone here will be able to answer how it did work on your machine, but does this matter given that it was "wrong" not to have added that line?

Marble2Go

@JonB Thank You for Your answer.
I want to know why I did not need to create an instance of a QCoreApplication on my development machine because I simply want to understand that strange behaviour. Understanding what is going on can help to solve stange errors where otherwise one would be lost.
Moreover, I think that deployment is a very crucial part of the whole work. I cannot test the product on every possible configuration of target machines. If the end user gets strange errors which I cannot reproduce I would be lost and unable to solve the issue. The presented case is not really a problem, as the error message tells what I have to do but in other cases it might not be as easy. Therefore, I think it is worth to know the reason for strange behaviour of the software.
By the way, I currently upgrades Qt on my development machine from 5.13.2 to 5.15.1, and now I get the same error message on my development machine, too, but an instance of QtCoreApplication still solves the problem.

JonB

@Marble2Go
As I said: in this case I think you are "lucky" if it ever worked with initializing Qt application. Just like: if you have an uninitialized variable in your code and you test its value, it may work on some machine or under debug but not release, but it's still wrong, and waiting to trip you up. You simply must write code to do Qt app init before making any further Qt calls. Period. :)

Christian Ehrlicher

@Marble2Go said in MySQL connection setup with diffent behaviour on deployed machine:

After that I deployed the "release" folder containing the files and folders:

How did you do it? Where lies qsqlmysql.dll? Hopefully in the sqldrivers subdir.