Qt 4.5.1 / MySQL 5.1, QSqlQuery::lastError() 1295

[wdezell]

I've got a Qt/MySQL app I have to make a few changes to. The app ran fine a few weeks ago under Kubuntu 8.04 (Qt 4.3.4 & MySQL 5.0.x) and runs fine on a CentOS 5.1 box (Qt 4.3.3 and MySQL 5.0.x). However, I just took advantage of a slow period to update my development box to Fedora 11 (Qt 4.5.1 via rpm from the Fusion repos and MySQL 5.1.35) and find now that my unchanged code is broken.

I have many stanzas similar to the following for executing a constructed query:

QString SQL;
 
QTextStream ( &SQL ) << "USE " << dbName (  );  // yields something like "USE foo"
query.exec ( SQL );
 
switch ( query.lastError (  ).number (  ) )
{
  case 1049:    // db does not exist
  ...
}

QString SQL;

QTextStream ( &SQL ) << "USE " << dbName (  );  // yields something like "USE foo"
query.exec ( SQL );

switch ( query.lastError (  ).number (  ) )
{
  case 1049:    // db does not exist
  ...
}

To copy to clipboard, switch view to plain text mode 

Under Qt 4.5.1 I am getting MySQL Error 1295 and the following message for code that ran fine under Qt 4.3.x and MySQL 5.0.x:

"This command is not supported in the prepared statement protocol yet QMYSQL3: Unable to prepare statement"

A little searching turns up links suggesting the behavior is the result of a bug in the 4.5-series QtMySQL drivers and their design to try and execute all queries first as a PREPARED query, then fall back if it's unsupported. (ref http://www.gossamer-threads.com/list...v/users/375066 for example). Is it possible that QSqlQuery::lastError() is not being internally reset after the fallback?

Can anyone suggest how I might correct this behavior without modifying all of my code or setting up a downgraded development system? Is this a Qt problem as my reading suggests or should I be looking into MySQL 5.1.x for answers?

Advice appreciated,
Bill

[wdezell]

Update:

The Qt 4.5.1 MySQL driver as packaged with Fedora 11 is broken.

I downloaded the Qt 4.4.3 source tarball and built from source (using the ./configure options below) and the same code which worked fine with Qt 4.3.3/4 but failed under Qt. 4.5.1 worked fine once more. It would appear that the changes in the Qt 4.5 QtMySQL driver (to first attempt to execute all queries as PREPARED queries) do not correctly fall back to conventional mode, or perhaps do but fail to clear the initially-encountered error code. Either way, the solution for now for me is to build using the Qt 4.4.3 source distribution.

./configure -debug -shared -no-fast -largefile -exceptions -accessibility -stl \
   -qt-sql-mysql -system-sqlite -qt3support -xmlpatterns \
   -phonon-backend -svg -webkit -assistant-webkit -system-zlib -qt-gif \
   -system-libtiff -system-libpng -system-libmng -system-libjpeg -openssl -optimized-qmake \
   -nis -pch -dbus -opengl -sm -xshape -xinerama -xcursor \
   -xfixes -xrandr -xrender -fontconfig -tablet -xkb -glib

./configure -debug -shared -no-fast -largefile -exceptions -accessibility -stl \
   -qt-sql-mysql -system-sqlite -qt3support -xmlpatterns \
   -phonon-backend -svg -webkit -assistant-webkit -system-zlib -qt-gif \
   -system-libtiff -system-libpng -system-libmng -system-libjpeg -openssl -optimized-qmake \
   -nis -pch -dbus -opengl -sm -xshape -xinerama -xcursor \
   -xfixes -xrandr -xrender -fontconfig -tablet -xkb -glib

To copy to clipboard, switch view to plain text mode 

(Note: When I have time I will grab a source distribution of Qt 4.5.1 and test against it to verify that it's not somehow a Fedora 11 packaging issue).