|Anonymous | Login||2016-05-28 06:00 CEST|
|Main | My View | View Issues | Change Log | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|08446||Bug reports||[All Projects] Survey design||public||2013-12-12 23:04||2014-01-26 15:59|
|Status||closed||Resolution||unable to reproduce|
|Target Version||Fixed in Version|
|Summary||08446: Cannot edit questions - "ActiveRecord Exception: The active record cannot be inserted to database because it is not new.|
I cannot edit any questions I created. Everytime I try to edit an already created question it raises the following exceotion:
The active record cannot be inserted to database because it is not new.
|Steps To Reproduce||Create Survey, Question group, sample question -> questions are not editable|
|I will donate to the project if issue is resolved||No|
|LimeSurvey build number OR git commit ID||131209|
|Database & DB-Version||Linux, MySQL5|
|Operating System (Server)||Linux (hosted: df.eu)|
|Webserver software & version||apache|
|Attached Files||question_DB_attribute.pdf [^] (30,977 bytes) 2013-12-19 12:57|
|Can not reproduce, except if you choose a second time the same code.|
edited on: 2013-12-19 11:02
I have reproduced this issue and this is how it occurred:
1. Choose to have only base language as English.
2. Create a question and answers for it
3. Now add another language
4. Add answers in the new language
5. Try to edit the question
6. The said error occurs.
Have a look at the lime_questions table which now has 2 entries for the same question - one for each language - but the qid column is 1 for English and 2 for the other language. Setting the qid column as 1 for the second language solves the issue. The lime_questions table has a compound key (qid, language) and hence the uniqueness of the primary key is not violated.
The code must now determine how to set the qid as same (same as that for the base language) for multiple entries - one for each language - when referring to the same question.
Many MySQL installations (including the latest on CentOS 6.5) suffer from the same issue even when the qid is set to be auto_increment while in a compound key state. In this case since it is not auto_increment, the code will have to be looked into whilst populating the records for non base languages.
edited on: 2013-12-19 12:45
Hi apmuthu and thanks.
But trye it again but can not reproduce
My MySQL is 5.1.72-2-log (Debian)
Bt maybe i made an error in reproducton : your survey is active ?
Tested with activated survey : same behaviour ...
Can not reproduce ....
What is the question type ?
edited on: 2013-12-19 12:54
Give us complete mysql configuration
PS: tested with array question type too : no problem
edited on: 2013-12-19 12:58
PS2: Did you upgrade and upgrade and upgrade from a very old version ?
PS3: maybe give us the print lime_questions attribute ?
edited on: 2013-12-19 16:37
Used Radio with and without comments with same error.
The said text of the error comes from either of the following 2 files (with it being the index for the all language array strings in framework/messages/*/yii.php):
1. framework/yiilite.php (Line 7640)
2. framework/db/ar/CActiveRecord.php (Line 1070)
abstract class CActiveRecord extends CModel
public function insert($attributes=null)
throw new CDbException(Yii::t('yii','The active record cannot be inserted to database because it is not new.'));
When a new language is used and the data for another language needs to be populated in a second pass (normally it would not allow it if the language pre-existed, all data for all languages need to be entered in the first pass itself), the said error will crop up since the insert id for the base language would not be available since it was inserted in the first pass.
Hence, during the updation of a question, if the insert for the base language fails, an update for it must be tried and then it's qid must be used for the updation/insertion for other language records since there is no last insert id of base language question available for use.
Alternatively, a delete before insert should be attempted atleast in the case of the questions table and possibly the answers table.
It's what i have :
- Create a survey (only one lang)
- Create a question ( 3 question type)
- Activate survey
- Answer to survey
- Add 2 new language:
All question have same qid (and same question text)
Can not reproduce : provide complete error HTML file with debug at 2 please.
edited on: 2013-12-22 07:40
1. Add extra language
2. Add a question and populate both languages
3. Save the question
4. View the lime_questions table
5. Notice that there are 2 different qid values for the same question in two languages (we need to have the same qid for both records with different language field entries)
This does not go away even if the ENGINE type is set to InnoDB from the existing MyISAM. Only the "qid" column is AUTO_INCREMENT and that can remain so.
This is because of the way an auto_increment key is treated in MySQL when it is clubbed with another field as the primary key. Reversing the order of the keys will result in the desired behaviour.
The fix is as below:
ALTER TABLE `lime_questions` DROP PRIMARY KEY, ADD PRIMARY KEY (`language`, `qid`);
The following sites provide example and workarounds and caveats (like issues during replication):
Yes understand rigth, BUT: my test case was with a 1.92 updated to 2.0 updated to 2.05.
And i have already PRIMARY KEY (`language`, `qid`);
I search when we have PRIMARY KEY (`qid`); : new installation ? Update from ?
Because we need to do this only if needed :)
|I am wondering that this issue is coming up now - this has never been a problem in the past and the PRIMARY KEY (`qid`,`language`,) has been there for at least 5 years?|
Unassign because con't find why we have this.
Carsten : i can enforce PRIMARY KEY :
- Removing PRIMARY KEY (`language`, `qid`); at table creation
- Remove all existing primary kay
- Set primary key to language,qid
But like you say : Why this happen now ?
We need to know the mysql version , complete verion number.
MySQL 5.2 ? MySQL 5.3 ? more ?
edited on: 2014-01-02 19:46
Server: Localhost via UNIX socket
Server version: 5.1.71
Protocol version: 10
MySQL charset: UTF-8 Unicode (utf8)
MySQL client version: 5.1.71
PHP extension: mysqli
Actually this has begun happening to some other projects like SimpleInvoices as well and that is how I traced this issue.
When we have a non auto_increment field (even like varchar) as the first part of a compound primary key, then the second field if it is an integer auto_increment type of field, will generate the necessary separate sequences for itself for each value of the first field. Otherwise, if the auto_increment field is the first in the primary key order, then it will take the next value by incrementing the maximum value of itself if it is not explicitly set in the insert statement (like being null in lime survey generic insert function). Any explicit value (if valid as compound primary key) if given in th einsert statement, it will be honoured.
|salamanderjoe: please activate debug mode in /application/config/config.php - then reproduce the error. You should get a full debug output. Please attach it as HTML file to this bug. Thank you!|
|Closed due to missing feedback.|
|2013-12-12 23:04||salamanderjoe||New Issue|
|2013-12-18 12:06||DenisChenu||Note Added: 27600|
|2013-12-19 10:56||apmuthu||Note Added: 27629|
|2013-12-19 11:02||apmuthu||Note Edited: 27629||View Revisions|
|2013-12-19 12:36||DenisChenu||Assigned To||=> DenisChenu|
|2013-12-19 12:36||DenisChenu||Status||new => assigned|
|2013-12-19 12:43||DenisChenu||Note Added: 27641|
|2013-12-19 12:45||DenisChenu||Note Edited: 27641||View Revisions|
|2013-12-19 12:50||DenisChenu||Note Added: 27642|
|2013-12-19 12:50||DenisChenu||Status||assigned => feedback|
|2013-12-19 12:50||DenisChenu||Reproducibility||have not tried => unable to reproduce|
|2013-12-19 12:54||DenisChenu||Note Edited: 27642||View Revisions|
|2013-12-19 12:54||DenisChenu||Note Added: 27643|
|2013-12-19 12:57||DenisChenu||File Added: question_DB_attribute.pdf|
|2013-12-19 12:58||DenisChenu||Note Edited: 27643||View Revisions|
|2013-12-19 16:35||apmuthu||Note Added: 27663|
|2013-12-19 16:36||apmuthu||Note Edited: 27663||View Revisions|
|2013-12-19 16:37||apmuthu||Note Edited: 27663||View Revisions|
|2013-12-19 16:38||DenisChenu||Note Added: 27664|
|2013-12-22 07:39||apmuthu||Note Added: 27692|
|2013-12-22 07:40||apmuthu||Note Edited: 27692||View Revisions|
|2013-12-22 11:25||DenisChenu||Note Added: 27693|
|2013-12-23 22:53||c_schmitz||Note Added: 27695|
|2014-01-02 19:13||DenisChenu||Assigned To||DenisChenu =>|
|2014-01-02 19:16||DenisChenu||Note Added: 27718|
|2014-01-02 19:39||apmuthu||Note Added: 27719|
|2014-01-02 19:46||apmuthu||Note Edited: 27719||View Revisions|
|2014-01-19 17:56||c_schmitz||Assigned To||=> c_schmitz|
|2014-01-19 17:56||c_schmitz||Status||feedback => assigned|
|2014-01-19 17:57||c_schmitz||Note Added: 28010|
|2014-01-19 17:57||c_schmitz||Status||assigned => feedback|
|2014-01-22 17:00||c_schmitz||Note Added: 28088|
|2014-01-26 15:59||c_schmitz||Note Added: 28206|
|2014-01-26 15:59||c_schmitz||Status||feedback => closed|
|2014-01-26 15:59||c_schmitz||Resolution||open => unable to reproduce|
|Copyright © 2000 - 2016 MantisBT Team|