Posted by seveinfo on September 2, 2009 at 12:28pm
10 followers
Jump to:
| Project: | Flexifield |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
hello,
I use flexifield with 2 text fields used in page content.
When I update the content, I have many error messages (one by flexifield) :
"user warning: Duplicate entry '3022' for key 1 query: drupal_write_record /* adminquartz : drupal_write_record */ INSERT INTO flexifield_items (item_id) VALUES (3022) in C:\wamp\www\Quartz\includes\common.inc on line 3436"
I looking for this error, but find nothing??
Thanks,
Christophe
Comments
#1
I have similar bug:
user warning: Duplicate entry '74' for key 1 query: INSERT INTO flexifield_items (item_id) VALUES (74) in ../Drupal 6/includes/common.inc on line 3468.
Not sure what is causing this, it happens only for some nodes.
#2
I'm getting the same error, has anyone been able to find the cause of this error and is there a way to fix it? Thank you.
#3
I'm getting this error with the latest dev version. Again, only for some node types. Very odd.
Edit: Flushing the caches after updating to the dev version fixed this for me
Edit again: Scratch that, it's still doing it :(
#4
Has this problem been solved? I get the same error when updating a node with a flexifield.
#5
this is probably not the only cause of the problem, but looking at where the item_id comes from, i am pretty sure that it depends on the AUTO_INCREMENT value of the node_revisions table being greater than the max item_id value in flexifield_items as well as greater than the max vid value from node_revisions itself.
we move databases around a lot and compress away the AUTO_INCREMENT value from the CREATE TABLE statement. so AUTO_INCREMENT for node_revisions ends up at max(vid) + 1. normally that's what we want, but for this problem i went into the database directly and tweaked it:
select max(item_id) as max_item_id from flexifield_items;select max(vid) as max_vid from node_revisions;
alter table node_revisions auto_increment = NEW_VALUE;
where NEW_VALUE = 1 + (max_item_id or max_vid, whichever is greater). (NEW_VALUE has to be a literal number, it's can't be the result of a query or such.)
it has stopped the Duplicate value warnings so far...
UPDATE: i should add, you can check with the query
show create table node_revisions;if the AUTO_INCREMENT value in there is greater than both the max item_id and the max vid, then none of this is relevant.
#6
I am still getting this error using the latest release. brad.bulger's solution makes sense, but in my case, the AUTO_INCREMENT value is already set to 1 greater than the max item_id. Anyone else find a solution for this?
#7
This error is also apparently behind data loss on node update. I'm migrating all content off this module as this is completely unacceptable.
#8
Do you have any ideas about what you'll use instead? I've also noticed the data loss issue, which has meant I've ensured revisions are always created when updating flexifield content types, but I haven't seen anything that does similar to what flexifield does.
#9
In my case I just had a flexifield that included a text area with a few configuration check boxes. As an alternative I just used a single text area and transformed it into separate text areas in the theme by splitting at <hr> tags. It's not an ideal solution, but at least it's safe.
#10
i've never lost any data editing nodes with flexifields, but i've never tried to use this on a content type that didn't have "Create new revision" enabled. trying that out in a test installation didn't show any problems. we have been beating on this pretty seriously and it has not been a problem with editing content in an installation. it only ever showed up moving content from one installation to another, because of those database issues.
#11
http://drupal.org/node/1173496
#12
We are experiencing some serious issues with Flexifield. We are at the point where we have to decide to continue using this module by either debugging the problem or moving to nodereference and redoing a big chunk of the website we just finished.
Scenario:
Everything seemed to work fine for almost a year until data became out-of-sync. Flexifield records all of a sudden started to appear on different nodes. We also noticed that MySQL was throwing the following errors during node saves:
"user warning: Duplicate entry '6107' for key 1 query: INSERT INTO flexifield_items (item_id) VALUES (6107) in ###/includes/common.inc on line 3528.
user warning: Duplicate entry '6108' for key 1 query: INSERT INTO flexifield_items (item_id) VALUES (6108) in ###/includes/common.inc on line 3528."
Flexifield seems to become very unstable when data corruption appears. We use it in conjunction with other modules (filefield, imagefield). We need a fail-safe in the module that will prevent data loss or data being linked to different nodes during a wrongful save or a browser crash during a save. We make intense use of the Flexifield which could also contribute to this problem.
We hope somebody experienced something similar and has a solution to the problem.
important modules being used:
- cck 6.x-2.7
- flexifield 6.x-1.x-dev
- filefield 6.x-3.10
- imagefield 6.x-3.10
- imageapi 6.x-1.8
- AHAH response 6.x-1.2
UPDATE: the method by Brad.Bulger seems to have fixed the Duplicate issue
select max(item_id) as max_item_id from flexifield_items;
select max(vid) as max_vid from node_revisions;
alter table node_revisions auto_increment = NEW_VALUE;
BUT we are still experiencing the flexifield tables getting out-of-sync and losing data after UPDATING a previously created node. initial node creation and flexifield elements work fine
#13
I'm experiencing the same out-of-sync trouble, although everything seemed to work fine for one year.
Did you finally fix this issue ? I'm at the point of moving to nodereference, if there's no solution to this trouble...
#14
For anyone still experiencing this issue you may find using the following tutorial to create your own custom CCK module a good solution: http://poplarware.com/articles/cck_field_module
I've now switched over to using this method instead of using flexifield as flexifield has been consistently losing data, and even saving data in the wrong node (I've not managed to narrow down what is causing these problems).
The tutorial's actually quite easy, there are some demo modules on the tutorial page that you can modify to get the fields you need. Once you've built one you'll be in a good position to make others quickly when you need them, and all in all it's a tidier and more elegant solution in my opinion.
#15
We found the problem!
Flexifield starts to get out-of-sync once Drupal Caching is turned on.
Also, keeping track of the error reporting logs are very important since they will state key problems like:
Duplicate entry '26958' for key 1 query: INSERT INTO flexifield_items (item_id) VALUES (26958) in common.inc on line 3528.
The error log will be problem free after disabling Drupal's caching mechanism. Turn off:
- Caching Mode
- Minimum cache lifetime
- Page compression
- Block cache
We need to find out why the Flexifield cannot save flexifield items properly with cache enabled. It overwrites older keys. It may be related to the node_revisions logic.
For now we will disable the cache until the problem is resolved.
#16
Great that there's progress being made. One thing I'd add is that the out of synch issues I've just experienced are on a dev site which hasn't had caching turned on yet (not very helpful I know! - sorry, I haven't got time at the moment to test any further. Deadlines etc.)
#17
Same problem here. All caching mechanisms are disabled and still getting all the errors. If someone find a solution or have a workaround, please share.
#18
Hi Everyone,
Back with some new findings. The magic query that fixes the issues for us:
select max(item_id) as max_item_id from flexifield_items;
select max(vid) as max_vid from node_revisions;
alter table node_revisions auto_increment = NEW_VALUE;
actually has a fatal flaw. Our MySQL database table for node_revisions reset the auto_increment number when the MySQL server is rebooting. That's why it was still breaking down our client's website randomly.
Now we need to figure out a way to make sure the NEW_VALUE never reset upon reboot or database transfer.
The comment left on: http://dev.mysql.com/doc/refman/5.1/en/example-auto-increment.html
could help resolve the ongoing problem.
As InnoDb forgets its highest auto_increment after server restart, you can set it again, if you have stored it anywhere. This happens often if you archive your data in an archive table and then delete it and then restart mysql. When archiving again this will result in duplicate key entries.
To work around this you can create a trigger which makes sure your auto_increment is higher than the auto_increment of your archive table:
delimiter //
drop trigger if exists trigger_autoinc_tbl;
CREATE TRIGGER trigger_autoinc_tbl BEFORE INSERT ON tbl
FOR EACH ROW
BEGIN
declare auto_incr1 BIGINT;
declare auto_incr2 BIGINT;
SELECT AUTO_INCREMENT INTO auto_incr1 FROM information_schema.TABLES WHERE table_schema=DATABASE() AND table_name='tbl';
SELECT AUTO_INCREMENT INTO auto_incr2 FROM information_schema.TABLES WHERE table_schema=DATABASE() AND table_name='tbl_archiv';
IF (auto_incr2 > auto_incr1 and NEW.id
I will update this topic as soon as we have more information.
#19
Problem:
Duplicate entries appear after a MySQL restart, shutdown or crash. MySQL resets the fix initially applied:
select max(item_id) as max_item_id from flexifield_items;select max(vid) as max_vid from node_revisions;
alter table node_revisions auto_increment = NEW_VALUE;
Solution:
function amicomd_flexifield_repair_required() {
// get flexifield id
$result = db_query("select max(item_id) as max_item_id from flexifield_items");
while ($row = db_fetch_array($result)) {
$latest_flexifield_id = $row['max_item_id'];
}
// get auto-increment id
$result = db_query("SHOW TABLE STATUS LIKE 'node_revisions'");
while ($row = db_fetch_array($result)) {
$node_revisions_structure = $row;
}
// is flexifield stable
if ($node_revisions_structure['Auto_increment'] <= $latest_flexifield_id) {
// have a higher increment than 1 just to be safe
$increment = 100;
// repair
$result = db_query("alter table node_revisions auto_increment = ".($latest_flexifield_id+$increment));
drupal_set_message('Database Auto-repair, latest ID: '.($latest_flexifield_id+$increment));
} else {
return false;
}
}
/**
* Implements hook_nodeapi().
*/
function amicomd_nodeapi(&$node, $op, $teaser = NULL, $page = NULL) {
// check database stability by comparing the node_revision ID with the flexifield ID
if ($op == 'update' || $op == 'insert') {
amicomd_flexifield_repair_required();
}