Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-68299

QSqlQuery produces error upon execution if it contains more than 1 instance of the same placeholder

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • P2: Important
    • 5.11.1
    • 5.11.0 RC 1
    • SQL Support
    • None
    • b0f3cc1594308ed3f3977bdcd451e8cf0eb0478d

    Description

      Tried the new Qt 5.11 RC since had a Qt SQLite plug-in crash with Qt 5.10.1, 5.9.5 and presumably older versions, too (hadn't checked). For unknown reason the QSqlQuery::prepare was crashing despite the pretty straightforward and trivial database manipulation scenario. The latter problem is the same as the one reported in this Qt SQL module bug. Thus switched to Qt 5.11, since it was specified as a target fix version for many of similar to the aforementioned bugs to see if the problem would be fixed by itself. It was but Qt 5.11 RC like some other previous Qt 5.x versions, excluding the crashing ones mentioned above, exposed a new QSqlQuery problem: when there is more than one instance of the same placeholder in a given query it fails upon execution. Here's is the simplest reproduction scenario of the issue:

      void failingQueryDueToRepeatingPlaceholder()
      {
          QSqlDatabase databaseConnection = QSqlDatabase::addDatabase( "QSQLITE" );
          if ( ! databaseConnection.isValid() )
          {
              return;
          }
      
          databaseConnection.setDatabaseName( ":memory:" );
          if ( ! databaseConnection.open() )
          {
              return;
          }
      
          QSqlQuery query( databaseConnection );
          query.setForwardOnly( true );
      #if 1
          const QString queryRaw = "SELECT 1 WHERE :num = 1 OR :num = 2";
          if ( ! query.prepare( queryRaw ) )
          {
              return;
          }
      
          query.bindValue( ":num", 1 );
      #else
          const QString queryRaw = "SELECT 1 WHERE :num1 = 1 OR :num2 = 2";
          if ( ! query.prepare( queryRaw ) )
          {
              return;
          }
      
          query.bindValue( ":num1", 1 );
          query.bindValue( ":num2", 1 );
      #endif
          if ( ! query.exec() )
          {
              const QSqlError error = query.lastError();
              if ( error.isValid() )
              {
                  qDebug() << "query error:" << endl
                           << error;
              }
      
              return;
          }
      
          int resultantRecordsCount = 0;
          while ( query.next() )
          {
              qDebug() << "result:" << query.value( 0 );
              ++ resultantRecordsCount;
          }
      
          qDebug() << "resultant records count =" << resultantRecordsCount;
      }
      

      Changing #if 1 to #if 0, so that the differently named placeholders' code steps into action, the query is correctly executed. Both preprocessor escaped code paths work correctly using Qt 5.10.1 but as mentioned this and other previous versions of Qt cause segmentation faults sometimes upon execution of queries in trivial scenarios. I see no explicit limitations towards the names of the placeholders mentioned in the QSqlQuery::bindValue's documentation except for the requirement to prepend a colon to the placeholder's name. Thus multiplicating a placeholder shouldn't be prohibited. As chehrlic mentioned in the Qt forum topic I've posted that it is bug QTBUG-66816 that introduced this QSqlQuery's placeholder limitation.
      It should be possible to have multiple instances of the same placeholder in a single query.

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            andysh Andy Shaw
            caravanio Caravanio Napajejenunedkov
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes