@tibor.pacalat: I can NOT reproduce this on our test system A using 7.0.5 which was set up from scratch.
But I CAN reprodce this at a system at which we went from 7.00 to 7.01 to 7.05. Has there been a certain fix applied recently and maybe our DB was not updated correctly during the update?

This is happening at application/helpers/admin/activate_helper.php

due to this part:

    if ((int)$questionTypesMetaData[$chkrow['type']]['settings']->answerscales > 0) {
        for ($i = 0; $i < (int)$questionTypesMetaData[$chkrow['type']]['settings']->answerscales; $i++) {
            $chaquery = Yii::app()->db->createCommand()
                ->select('COUNT(aid)')
                ->from('{{answers}}')
                ->where('qid = :qid and scale_id=:scaleid', [':qid' => $chkrow['qid'], ':scaleid' => $i]);
            $chacount = $chaquery->queryScalar();
            if ($chacount == 0) {
                $failedcheck[] = array($chkrow['qid'], flattenText($chkrow['question'], true, true, 'utf-8', true), ": " . gT("This question has missing answer options."), $chkrow['gid']);
            }
        }
    }

It seems that script 703 was not executed at your end which has its purpose of updating question theme to expect subquestions to exist rather than answers because from now on ranking questions will have subquestions rather than answers to choose from. The error message clearly expected to have at least one answer whereas the correct expectation would be to have at least 1 subquestion. If you run

select * from lime_question_themes where question_type = 'R';

in your database you should find ranking and ranking_advanced and in the settings you should have something like this:

{"subquestions":"1","answerscales":"0","hasdefaultvalues":"0","assessable":"1","class":"ranking"}

where subquestions being 1 means we expect at least a subquestion to exist, whilst answerscales needs to be 0. Since you had it not being 0, you've got the validation issue you reported.

@lajosarpad thanks a lot for this detailed analysis. That explains the problem very well.

Is there any way to execute script 703 to deal with the inconsistent database structure?

A way to do that is to:

1. Change version.php to have a higher value (increase it by one)
2. Copy-paste the 703 script corresponding that number, maybe Update_709.php, but I did not double-check the number, so whatever number you have in version.php, that's the script number you need and in this copy the class name needs to be the same as the filename without the extension
3. Reload an admin page and check these in the database
4. Undo the change in version.php
5. In the database you have a {{settings_global}} table that contains pairs of stg_name and stg_value, we are interested in the record whose stg_name is 'DBVersion'. The stg_number needs to be set to the one you have in version.php so future scripts will be executed
6. Remove the temporary copy

Explanation:

• version.php defines what the desired db version is
• in {{settings_global}} the DBVersion record specifies what version you currently in
• we artificially change version.php to want to update a future script (that we are about to temporarily create)
• we create a copy of the script we wish to execute, renaming the class and the file accordingly
• load a page to trigger the script
• adjust version.php as well as {{settings_global}} so the script versioning will still work well in the future.

@lajosarpad, thanks for this very helpful step-by-step list. This solved the problem. I think we can close the ticket.

This is resolved in the latest v7 version.