Solved QSqlQuery produces error if containing two equally named placeholders

[napajejenunedk0]

Hello, all.

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 despite the scenario is pretty straightforward and the query is simple enough. The problem is the same as the one reported in this Qt SQL module bug. The problem is that Qt 5.11 RC like some other previous Qt 5.x versions, excluding the crashing ones mentioned above, causes a problem when there is more than one instance of the same placeholder in a given query. 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() )
    {
        return;
    }

    const QSqlError error = query.lastError();
    if ( error.isValid() )
    {
        qDebug() << "query error:" << endl
                 << error;
    }
}

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 it causes segmentation faults sometimes upon execution of queries in trivial scenarios. Would submit a bug, but is there an explicit prescription to avoid using multiple instances of the same placeholder? 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.

[JonB]

@napajejenunedk0 said in QSqlQuery produces error if containing two equally named placeholders:

The problem is the same as the one reported in this Qt SQL module bug. The problem is that Qt 5.11 RC like some other previous Qt 5.x versions, excluding the crashing ones mentioned above, causes a problem when there is more than one instance of the same placeholder in a given query.

Where in the link you quote (https://bugreports.qt.io/browse/QTBUG-67492) does it say anything about your "same placeholders"? That one is about table missing....?

[napajejenunedk0]

@JonB Follow the semantic context carefully. "The problem is the same as the one reported in this Qt SQL module bug." relates to the pre-Qt 5.11 RC crashes, not to the error produced by a QSqlQuery in Qt 5.11 RC due to multiple instances of the same placeholder.

[JonB]

@napajejenunedk0
Oh, I didn't follow at all from your post that the quoted link does not refer to your problem. So, your problem (in 5.11) has nothing to do with that bug, right?

I do not see why you should not be able to multi-use a placeholder. Unless an expert here says otherwise, that seems valid to report as a bug. I take it you have no interest in possible workarounds, as you are looking for the feature to work generically, right?

[Christian Ehrlicher]

In general it is allow to use two placeholder with the same name but there was an addition due to https://bugreports.qt.io/browse/QTBUG-66816 which prevents this when there is only one placeholder.

[napajejenunedk0]

@JonB Exactly, I want to use the standard approach - using as many instances of the same placeholder as desired, but saw using different names of the placeholder as the only practically possible option, since Qt 5.11 on ... and the most rapidly achievable one. The problem in 5.11 has nothing to do with the cited bug, correct, but it is this bug's (and some others as well) fixed version (Qt 5.11) that motivated the change to Qt 5.11, so that to avoid the crash, which led to finding this problem.

@Christian-Ehrlicher, wow. This should be explicitly documented for sure if it is going to stay officially like this, which shouldn't happen for sure.

[napajejenunedk0]

@Christian-Ehrlicher, thanks for the guidance. Marking the topic as solved, since a Qt fix is presumably being awaited. Filed a bug report.