Cannot insert duplicate key: MySQL to SQL server - mysql

Question

Suppose we have the following chunk of data (SQL table):
Col-A Col-B Col-C Col-D
1 1 1 1
1 1 1 2
1 1 1 3
2 2 2 4
2 2 2 5
In MySQL the table is defined as:
CREATE TABLE `my_table` (
`Col-A` INT(10) UNSIGNED NOT NULL DEFAULT '0',
`Col-B` INT(10) UNSIGNED NOT NULL DEFAULT '0',
`Col-C` INT(10) UNSIGNED NOT NULL DEFAULT '0',
`Col-D` INT(10) UNSIGNED NOT NULL DEFAULT '0',
PRIMARY KEY (`Col-A`, `Col-B`, `Col-C`),
KEY `my_index` (`Col-D`) USING BTREE
);
I need to convert MySQL database to SQL Server. Here is my initial attempt:
CREATE TABLE my_table (
Col-A INT NOT NULL DEFAULT(0),
Col-B INT NOT NULL DEFAULT(0),
Col-C INT NOT NULL DEFAULT(0),
Col-D INT NOT NULL DEFAULT(0),
CONSTRAINT my_pk PRIMARY KEY NONCLUSTERED (Col-A, Col-B, Col-C)
)
CREATE INDEX my_idx ON my_table(Col-D)
When I try to import data (I use bcp), the following error occurs:
Cannot insert duplicate key ... The duplicate key is (1, 1, 1)
I suspect that something is wrong with my_pk and my_idx definitions. Any pointers or suggestions?

Answer 1

You know the definition of a primary key?
http://en.wikipedia.org/wiki/Primary_key
In the relational model of database design, a unique key or primary key is a set of attributes whose values uniquely define the characteristics of each row.
When the combination of Col-A + Col-B + Col-C is not unique you violate the primary key constraint and thus SQL server won't allow it.
Your options are:
Extend the PK to include Col-D
Drop the PK and use a (clustered or not) Index on Col-A, Col-B and Col-C
Fix the data so it doesn't violate the PK constraint (either drop records or alter/correct incorrect records)
Add a synthetic (or surrogate) key (see mrjoltcola's answer)
Which option to choose is up to you and depends on your requirements. We can't answer that for you based only on the information in your question.
Why MySQL allowed this data to get in there in the first place... *shrugs* MySql is a "funny" beast. Maybe the PK constraint was added after the data was already in the table, maybe it's a really old version, maybe you're using MyISAM instead of InnoDB. I'm not sure which but each of these reasons (or combination of them) are a good guess or, at least, were decent guesses some time / versions ago. Either way: it shouldn't have been possible (even if the PK constraint was added later; MySQL should've denied adding it since the data in the table was conflicting) but MySQL had, and does have, it's own weird ways of reasoning about these kind of things. Strict mode helps if I recall correctly but I can't remember if that only works on InnoDB tables or also on MyISAM etc. Either way; they made a nice mess of it back in the day; I (or you) shouldn't have to worry about remembering the differences in underlying MyISAM/InnoDB/Whatevs etc. or which specific version allows what (not) to happen or if you need strict mode or not for this-or-that for basic stuff like PK's to work correctly*
* Each RDBMS has it's quirks; I'm sure there's a good reason for some switches/toggles/settings/whatevs to tweak some details, I'm saying PK's should be PK's no matter what.

Answer 2

For your data requirement, you cant use cols (A,B,C) as primary key. You need to either add (D) to the key, or add a surrogate key. See RobIII's answer https://stackoverflow.com/a/24703970/257090 for why.
I recommend you go with the latter, add an ID primary key so you have a single field key:
CREATE TABLE my_table (
ID INT IDENTITY PRIMARY KEY,
ColA INT NOT NULL DEFAULT(0),
ColB INT NOT NULL DEFAULT(0),
ColC INT NOT NULL DEFAULT(0),
ColD INT NOT NULL DEFAULT(0),
UNIQUE(ColA,ColB,ColC,ColD)
)
INSERT INTO my_table(cola, colb, colc, cold) VALUES(1,1,1,1)
INSERT INTO my_table(cola, colb, colc, cold) VALUES(1,1,1,2)
INSERT INTO my_table(cola, colb, colc, cold) VALUES(1,1,1,3)
INSERT INTO my_table(cola, colb, colc, cold) VALUES(2,2,2,4)
INSERT INTO my_table(cola, colb, colc, cold) VALUES(2,2,2,5)
SELECT * FROM my_table
ID ColA ColB ColC ColD
----------- ----------- ----------- ----------- -----------
1 1 1 1 1
2 1 1 1 2
3 1 1 1 3
4 2 2 2 4
5 2 2 2 5
(5 row(s) affected)
Now I can identify each row by a single key value.
delete from my_table where ID = 5
This is much more practical for any code you write against the database or ORMs you use.
NOTE: with surrogate (or synthetic keys) it is still important that you add any additional constraints to enforce data integrity of the actual data. A surrogate key doesn't keep you from inserting 1,1,1,1 multiple times, so add a unique constraint/index to those fields in addition to the primary key ID.