View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|04731||Bug reports||[All Projects] Import/Export||public||2010-11-10 12:04||2010-12-07 14:14|
|Target Version||Fixed in Version||1.90+|
|Summary||04731: Exported/Copied survey structures are lacking type t for subquestions.No activation possible|
|Description||Exported or copied survey structures are missing the type declaration for subquestions type = t.|
When creating the survey from scratch the type is always set.
|Steps To Reproduce||Just copy or reimport a survey structure and try to activated it.|
the database / export is showing missing type declaration type=t for subquestions.
|Tags||No tags attached.|
|Complete LimeSurvey version number (& build)||9459|
|I will donate to the project if issue is resolved||No|
|Database & DB-Version||MySQL 5.0.91|
|Operating System (Server)||CENTOS 4.8 i686|
|Webserver software & version||Apache 1.3.42|
|PHP Version||PHP 5.2.14 SuPHP|
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.
limesurvey_survey_73537.lss (20,645 bytes)
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.
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, 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.|
|2010-11-10 12:04||jelo||New Issue|
|2010-11-10 12:31||jelo||Note Added: 13478|
|2010-11-10 15:37||jelo||Note Edited: 13478||View Revisions|
|2010-11-10 16:42||c_schmitz||Assigned To||=> c_schmitz|
|2010-11-10 16:42||c_schmitz||Status||new => assigned|
|2010-11-10 16:43||c_schmitz||Note Added: 13481|
|2010-11-10 18:41||jelo||Note Added: 13496|
|2010-11-10 18:41||jelo||File Added: limesurvey_survey_73537.lss|
|2010-11-10 18:42||jelo||Note Edited: 13496||View Revisions|
|2010-11-10 20:21||jelo||Note Added: 13498|
|2010-11-10 20:38||jelo||Note Edited: 13498||View Revisions|
|2010-11-11 00:18||jelo||Note Added: 13501|
|2010-11-12 23:59||c_schmitz||Assigned To||c_schmitz => lemeur|
|2010-11-12 23:59||c_schmitz||Note Added: 13516|
|2010-11-13 09:49||lemeur||Assigned To||lemeur => c_schmitz|
|2010-11-13 09:52||lemeur||Note Added: 13519|
|2010-11-22 13:32||c_schmitz||Note Added: 13567|
|2010-11-22 22:11||lemeur||Note Added: 13573|
|2010-11-22 22:48||c_schmitz||Note Added: 13578|
|2010-11-28 02:24||c_schmitz||Note Added: 13647|
|2010-11-28 02:24||c_schmitz||Status||assigned => resolved|
|2010-11-28 02:24||c_schmitz||Fixed in Version||=> 1.90+|
|2010-11-28 02:24||c_schmitz||Resolution||open => fixed|
|2010-12-07 14:14||c_schmitz||Note Added: 13714|
|2010-12-07 14:14||c_schmitz||Status||resolved => closed|