Question

I’ve got a script running this update:

UPDATE `Cq_Item` 
SET     `rfq_item_id` = '9',
    `value` = 'No Bid',
    `datetime_created` = '2012-10-23T20:54:42+00:00',
    `id` = '101' 
WHERE `id` = '101'

Against this table:

CREATE TABLE IF NOT EXISTS `cq_item` (
  `id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
  `rfq_item_id` mediumint(8) unsigned NOT NULL,
  `product_id_quoted` mediumint(8) unsigned DEFAULT NULL,
  `quantity` mediumint(6) unsigned DEFAULT '0',
  `value` float(10,4) NOT NULL,
  `datetime_created` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `rfq_item_id` (`rfq_item_id`,`product_id_quoted`,`quantity`,`value`),
  KEY `product_id` (`product_id_quoted`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=102 ;

and it’s throwing this error:

1062 – Duplicate entry ‘9-321742-1-0.0000’ for key ‘rfq_item_id’

Granted, i’m no SQL guru, but throwing a dupe error on an update seems a little less than intuitive to me.

I understand why such an error would get thrown on an INSERT, but I can use some help figuring out what i’m doing wrong to get that on this UPDATE 🙂

Answer 1

An update actually performs two separate operations (when conditions are met of course), a DELETE and then an INSERT. You probably need to make sure that your UPDATE is not causing the row with id = 101 to violate your unique key that is already in place for another row.

So say you had two rows like this before attempting the update

id   |   rfq_item_id |   product_id_quoted  | quantity | value   | datetime_creates
100  |   9           |   9                  |    1     | 0.0000  | <some datetime>
101  |   10          |   9                  |    1     | 0.0000  | <some datetime>

Your UPDATE would throw the exact error you are seeing upon execution, because the rfq_item_id/product_id_quoted/quantity/value unique key would be the same.

I would guess your problem is related to trying to set a string value of “No Bid” on the field value which is defined as a float. You thus will get a 0.0000 value in the update.

Also as mentioned in comment to original question, it is generally considered to be bad SQL practice to try to “set” the value of the primary key that you are using in the WHERE clause of an UPDATE statement. That is unless to really have a reason to change the primary key as part of the update.