View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
08446 | Bug reports | Survey editing | public | 2013-12-12 23:04 | 2014-01-26 15:59 |
Reporter | salamanderjoe | Assigned To | c_schmitz | ||
Priority | high | Severity | partial_block | ||
Status | closed | Resolution | unable to reproduce | ||
Product Version | 2.05+ | ||||
Summary | 08446: Cannot edit questions - "ActiveRecord Exception: The active record cannot be inserted to database because it is not new. | ||||
Description | Hello, 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 | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
Bug heat | 6 | ||||
Complete LimeSurvey version number (& build) | 131209 | ||||
I will donate to the project if issue is resolved | No | ||||
Browser | |||||
Database type & version | Linux, MySQL5 | ||||
Server OS (if known) | Linux (hosted: df.eu) | ||||
Webserver software & version (if known) | apache | ||||
PHP Version | 5 | ||||
Can not reproduce, except if you choose a second time the same code. |
|
I have reproduced this issue and this is how it occurred:
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. |
|
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 ? PS: Can not reproduce .... What is the question type ? |
|
Please: PS: tested with array question type too : no problem |
|
PS2: Did you upgrade and upgrade and upgrade from a very old version ? PS3: maybe give us the print lime_questions attribute ? |
|
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):
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 :
Can not reproduce : provide complete error HTML file with debug at 2 please. |
|
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 The following sites provide example and workarounds and caveats (like issues during replication): http://stackoverflow.com/questions/5416548/mysql-two-column-primary-key-with-auto-increment |
|
Hi Yes understand rigth, BUT: my test case was with a 1.92 updated to 2.0 updated to 2.05. I search when we have PRIMARY KEY ( 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 ( |
|
Unassign because con't find why we have this. Carsten : i can enforce PRIMARY KEY :
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 ? |
|
MySQL
Web server
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! |
|
Feedback please? |
|
Closed due to missing feedback. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
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 | |
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 | |
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 | |
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 | |
2013-12-19 16:35 | apmuthu | Note Added: 27663 | |
2013-12-19 16:36 | apmuthu | Note Edited: 27663 | |
2013-12-19 16:37 | apmuthu | Note Edited: 27663 | |
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 | |
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 | |
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 |
2019-11-01 17:25 | c_schmitz | Category | Survey design => Survey editing |