The mysql database table structure of lime_questions are containing standard values for type = T and other = N when doing a fresh installation. The updated installation still showing the old structure without standard values.

Reason might be the broken update routine some builds ago. There might be a mismatch in the dbversion with controls the sql upgrade routines. Version set but structure not changed.

Since this is causing a lot of problems (conditions cannot be imported too) this ticket won't be fruitful anymore and can be closed.

I am sorry for wasting time.

That is weird. I will schedule another test for update routines from early versions.

Faulty Import of conditions seem to be a specific problem with certain kind of conditions.

I found that a multioption question as trigger for a condition isn't imported.
I attached a short survey.

Not sure if the export is faulty or the import. I uploaded the demo survey to the demo installation of limesurvey on limesurvey.org and 0 conditions were imported.

If I remember it right, a few had problems with the update routine

"Allowed memory size of xxx bytes exhausted" where a fix was provides to get the comfortupdate running again.

I had this on the 7th Oct 2010. Perhaps in the timeframe a few people got a not update dbstructure. I haven't checked if it is possible that the db version update without updating the structure itself and the data.

I updated another old installation a few days ago via comfortupdate and the mysql structure was updated correctly. There was no break of the updateroutine.

Sorry that I didn't noted the build numbers.

1. Page
   Yes/No
   Multiple options

2. Page
   Condition on Yes/No only -> Condition is successful copied
   Condition on Yes/No and Multiple options -> Conditions are successful copied
   Condition on Multiple options only -> Condition is not copied

Checked the upgrade route - in general it was fine.
Thibault, can you have a look at the conditions issue, plz?

Partly fixed in rev 9479.
==> fixed for conditions on single-checkboxes only.

I assign this one back to you Carsten, since fixing for conditions set on the set of checkboxes require changes to the createFieldmap function.

Thibault

Thibault, can you tell me what exactly you need?

Conditions not only use true fieldnames, but also meta fieldnames.

In the past, conditions for mutliple options were only using an "SGQ" meta fieldname that is representing the group of checkboxes. Thus adding a condition with possible values X,Y and Z for the SGQ meta fieldname really means either SGQX or SGQY or SGQZ is set (ORed conditions).
==> This was how conditions were implemented historically for this kind of questions.

CreateFieldmap doesn't return SGQ meta fieldname for multiple options as this is not a true fieldname. Only the full SGQA fieldnames are really used in DB.

The importsurvey script uses createFieldmap which explains why some conditions can't be imported.

Ok, thanks. I will have a look.

Fixed in rev. 9543

Released in latest 1.90+ version.