Can't create foreign key using individual columns against multiple-column primary key
up vote
0
down vote
favorite
I can not find out what is wrong that i am getting the error message:
Msg 1776, Level 16, State 0, Line 56 There are no primary or candidate
keys in the referenced table 'Airplane_type' that match the
referencing column list in the foreign key
'FK_Airplane_make__68487DD7'. Msg 1750, Level 16, State 0, Line 56
Could not create constraint. See previous errors.
Here is that section of the query:
CREATE TABLE Airplane_type
(
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
type VARCHAR NOT NULL,
business_capacity INT NOT NULL,
economy_capacity INT NOT NULL,
range INT NOT NULL,
weight INT NOT NULL,
length INT NOT NULL,
wingspan INT NOT NULL,
PRIMARY KEY(make, model)
);
CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
make VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(make),
model VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(model)
);
Any help is greatly appreciated, thanks
sql-server-2008 constraints
add a comment |
up vote
0
down vote
favorite
I can not find out what is wrong that i am getting the error message:
Msg 1776, Level 16, State 0, Line 56 There are no primary or candidate
keys in the referenced table 'Airplane_type' that match the
referencing column list in the foreign key
'FK_Airplane_make__68487DD7'. Msg 1750, Level 16, State 0, Line 56
Could not create constraint. See previous errors.
Here is that section of the query:
CREATE TABLE Airplane_type
(
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
type VARCHAR NOT NULL,
business_capacity INT NOT NULL,
economy_capacity INT NOT NULL,
range INT NOT NULL,
weight INT NOT NULL,
length INT NOT NULL,
wingspan INT NOT NULL,
PRIMARY KEY(make, model)
);
CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
make VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(make),
model VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(model)
);
Any help is greatly appreciated, thanks
sql-server-2008 constraints
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I can not find out what is wrong that i am getting the error message:
Msg 1776, Level 16, State 0, Line 56 There are no primary or candidate
keys in the referenced table 'Airplane_type' that match the
referencing column list in the foreign key
'FK_Airplane_make__68487DD7'. Msg 1750, Level 16, State 0, Line 56
Could not create constraint. See previous errors.
Here is that section of the query:
CREATE TABLE Airplane_type
(
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
type VARCHAR NOT NULL,
business_capacity INT NOT NULL,
economy_capacity INT NOT NULL,
range INT NOT NULL,
weight INT NOT NULL,
length INT NOT NULL,
wingspan INT NOT NULL,
PRIMARY KEY(make, model)
);
CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
make VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(make),
model VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(model)
);
Any help is greatly appreciated, thanks
sql-server-2008 constraints
I can not find out what is wrong that i am getting the error message:
Msg 1776, Level 16, State 0, Line 56 There are no primary or candidate
keys in the referenced table 'Airplane_type' that match the
referencing column list in the foreign key
'FK_Airplane_make__68487DD7'. Msg 1750, Level 16, State 0, Line 56
Could not create constraint. See previous errors.
Here is that section of the query:
CREATE TABLE Airplane_type
(
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
type VARCHAR NOT NULL,
business_capacity INT NOT NULL,
economy_capacity INT NOT NULL,
range INT NOT NULL,
weight INT NOT NULL,
length INT NOT NULL,
wingspan INT NOT NULL,
PRIMARY KEY(make, model)
);
CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
make VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(make),
model VARCHAR NOT NULL FOREIGN KEY REFERENCES Airplane_type(model)
);
Any help is greatly appreciated, thanks
sql-server-2008 constraints
sql-server-2008 constraints
edited Apr 16 '12 at 21:50
Aaron Bertrand
205k27357401
205k27357401
asked Apr 16 '12 at 21:46
Troy Loberger
168422
168422
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
up vote
3
down vote
accepted
You've created the primary key on two columns, shouldn't the foreign key be created on two columns rather than individually? You can't reference the model column in an individual foreign key because there is nothing in the original table that guarantees that model is unique.
CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
CONSTRAINT FK_Airplane_type FOREIGN KEY (make, model)
REFERENCES Airplane_type(make, model)
);
Also, why are you using VARCHAR
without specifying a length? Please read this blog post:
- Bad habits to kick : declaring VARCHAR without (length)
Despite 15 years+ of sql server I, didn't know you could do that, course they aren't helping me comne up with a reason why you'd want to.
– Tony Hopkinson
Apr 16 '12 at 22:00
Another tip for you @Troy. Put names in for your constraints, use some standard naming convention, it's always helped me when the wheels came off.
– Tony Hopkinson
Apr 16 '12 at 22:03
add a comment |
up vote
1
down vote
The column referenced by a foreign key has to be constrained by a primary key or unique index. Since your primary key is the composite of two columns (make, model), the foreign key should also reference that same composite pair.
add a comment |
up vote
0
down vote
CREATE TABLE Airplane_type
(
airplane_type_id not null Identity(1,1),
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
type VARCHAR NOT NULL,
business_capacity INT NOT NULL,
economy_capacity INT NOT NULL,
range INT NOT NULL,
weight INT NOT NULL,
length INT NOT NULL,
wingspan INT NOT NULL,
CONSTRAINT PK_AIRPLANE_TYPE PRIMARY KEY(airplane_type_id),
Constraint UK_Spotted_By_AARON Unique Key (make, model)
);
CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL,
airplane_type_id int not null CONSTRAINT FK_Airplane_AirPlane_Type
Foreign Key References(AirPlane.Airplane_type_id),
Constraint PK_Airplane Primary Key (Airplane_id),
);
Using parts of a compound key as a constraint isn't a goer a far as I know, and if you normalise, it's unnecessary. The way you had your schema an airplane with a make and model combination not in your airplane type table was valid.
How does adding an identity column and removing the key onmake,model
help anything? Now you can have duplicatemake,model
because your only unique constraint is on the meaningless identity value. At the very least you should still have a unique constraint onmake,model
or vice-versa (a foreign key constraint can reference a unique constraint in SQL Server, not just a primary key, so you can have both).
– Aaron Bertrand
Apr 16 '12 at 21:59
I'm going to take a wild guess here and predict you don't sit on the same side of the surrogate versus natural keys debate. I forgot teh unique constraint, give me a minute. Meaningless identity value is the point...
– Tony Hopkinson
Apr 16 '12 at 22:09
No I agree about surrogates I just think an IDENTITY is too commonly thrown onto a table serving as the only unique aspect of the table. My answer to the question was based on explaining why the error message was being thrown, not on redesigning the table. In either design, I fail to see the purpose of the second table.
– Aaron Bertrand
Apr 16 '12 at 22:15
Also you've indicated the primary key constraint twice in your second table - once unnamed, once named.
– Aaron Bertrand
Apr 16 '12 at 22:18
Ah the cookie cutter auto number approach for tables that "don't have a key". Not a big fan of that myself, more of a rectangular array than a Table, that one.
– Tony Hopkinson
Apr 16 '12 at 22:21
|
show 1 more comment
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
You've created the primary key on two columns, shouldn't the foreign key be created on two columns rather than individually? You can't reference the model column in an individual foreign key because there is nothing in the original table that guarantees that model is unique.
CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
CONSTRAINT FK_Airplane_type FOREIGN KEY (make, model)
REFERENCES Airplane_type(make, model)
);
Also, why are you using VARCHAR
without specifying a length? Please read this blog post:
- Bad habits to kick : declaring VARCHAR without (length)
Despite 15 years+ of sql server I, didn't know you could do that, course they aren't helping me comne up with a reason why you'd want to.
– Tony Hopkinson
Apr 16 '12 at 22:00
Another tip for you @Troy. Put names in for your constraints, use some standard naming convention, it's always helped me when the wheels came off.
– Tony Hopkinson
Apr 16 '12 at 22:03
add a comment |
up vote
3
down vote
accepted
You've created the primary key on two columns, shouldn't the foreign key be created on two columns rather than individually? You can't reference the model column in an individual foreign key because there is nothing in the original table that guarantees that model is unique.
CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
CONSTRAINT FK_Airplane_type FOREIGN KEY (make, model)
REFERENCES Airplane_type(make, model)
);
Also, why are you using VARCHAR
without specifying a length? Please read this blog post:
- Bad habits to kick : declaring VARCHAR without (length)
Despite 15 years+ of sql server I, didn't know you could do that, course they aren't helping me comne up with a reason why you'd want to.
– Tony Hopkinson
Apr 16 '12 at 22:00
Another tip for you @Troy. Put names in for your constraints, use some standard naming convention, it's always helped me when the wheels came off.
– Tony Hopkinson
Apr 16 '12 at 22:03
add a comment |
up vote
3
down vote
accepted
up vote
3
down vote
accepted
You've created the primary key on two columns, shouldn't the foreign key be created on two columns rather than individually? You can't reference the model column in an individual foreign key because there is nothing in the original table that guarantees that model is unique.
CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
CONSTRAINT FK_Airplane_type FOREIGN KEY (make, model)
REFERENCES Airplane_type(make, model)
);
Also, why are you using VARCHAR
without specifying a length? Please read this blog post:
- Bad habits to kick : declaring VARCHAR without (length)
You've created the primary key on two columns, shouldn't the foreign key be created on two columns rather than individually? You can't reference the model column in an individual foreign key because there is nothing in the original table that guarantees that model is unique.
CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL PRIMARY KEY,
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
CONSTRAINT FK_Airplane_type FOREIGN KEY (make, model)
REFERENCES Airplane_type(make, model)
);
Also, why are you using VARCHAR
without specifying a length? Please read this blog post:
- Bad habits to kick : declaring VARCHAR without (length)
edited Nov 10 at 21:31
answered Apr 16 '12 at 21:49
Aaron Bertrand
205k27357401
205k27357401
Despite 15 years+ of sql server I, didn't know you could do that, course they aren't helping me comne up with a reason why you'd want to.
– Tony Hopkinson
Apr 16 '12 at 22:00
Another tip for you @Troy. Put names in for your constraints, use some standard naming convention, it's always helped me when the wheels came off.
– Tony Hopkinson
Apr 16 '12 at 22:03
add a comment |
Despite 15 years+ of sql server I, didn't know you could do that, course they aren't helping me comne up with a reason why you'd want to.
– Tony Hopkinson
Apr 16 '12 at 22:00
Another tip for you @Troy. Put names in for your constraints, use some standard naming convention, it's always helped me when the wheels came off.
– Tony Hopkinson
Apr 16 '12 at 22:03
Despite 15 years+ of sql server I, didn't know you could do that, course they aren't helping me comne up with a reason why you'd want to.
– Tony Hopkinson
Apr 16 '12 at 22:00
Despite 15 years+ of sql server I, didn't know you could do that, course they aren't helping me comne up with a reason why you'd want to.
– Tony Hopkinson
Apr 16 '12 at 22:00
Another tip for you @Troy. Put names in for your constraints, use some standard naming convention, it's always helped me when the wheels came off.
– Tony Hopkinson
Apr 16 '12 at 22:03
Another tip for you @Troy. Put names in for your constraints, use some standard naming convention, it's always helped me when the wheels came off.
– Tony Hopkinson
Apr 16 '12 at 22:03
add a comment |
up vote
1
down vote
The column referenced by a foreign key has to be constrained by a primary key or unique index. Since your primary key is the composite of two columns (make, model), the foreign key should also reference that same composite pair.
add a comment |
up vote
1
down vote
The column referenced by a foreign key has to be constrained by a primary key or unique index. Since your primary key is the composite of two columns (make, model), the foreign key should also reference that same composite pair.
add a comment |
up vote
1
down vote
up vote
1
down vote
The column referenced by a foreign key has to be constrained by a primary key or unique index. Since your primary key is the composite of two columns (make, model), the foreign key should also reference that same composite pair.
The column referenced by a foreign key has to be constrained by a primary key or unique index. Since your primary key is the composite of two columns (make, model), the foreign key should also reference that same composite pair.
answered Apr 16 '12 at 21:50
Joe Stefanelli
109k13189203
109k13189203
add a comment |
add a comment |
up vote
0
down vote
CREATE TABLE Airplane_type
(
airplane_type_id not null Identity(1,1),
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
type VARCHAR NOT NULL,
business_capacity INT NOT NULL,
economy_capacity INT NOT NULL,
range INT NOT NULL,
weight INT NOT NULL,
length INT NOT NULL,
wingspan INT NOT NULL,
CONSTRAINT PK_AIRPLANE_TYPE PRIMARY KEY(airplane_type_id),
Constraint UK_Spotted_By_AARON Unique Key (make, model)
);
CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL,
airplane_type_id int not null CONSTRAINT FK_Airplane_AirPlane_Type
Foreign Key References(AirPlane.Airplane_type_id),
Constraint PK_Airplane Primary Key (Airplane_id),
);
Using parts of a compound key as a constraint isn't a goer a far as I know, and if you normalise, it's unnecessary. The way you had your schema an airplane with a make and model combination not in your airplane type table was valid.
How does adding an identity column and removing the key onmake,model
help anything? Now you can have duplicatemake,model
because your only unique constraint is on the meaningless identity value. At the very least you should still have a unique constraint onmake,model
or vice-versa (a foreign key constraint can reference a unique constraint in SQL Server, not just a primary key, so you can have both).
– Aaron Bertrand
Apr 16 '12 at 21:59
I'm going to take a wild guess here and predict you don't sit on the same side of the surrogate versus natural keys debate. I forgot teh unique constraint, give me a minute. Meaningless identity value is the point...
– Tony Hopkinson
Apr 16 '12 at 22:09
No I agree about surrogates I just think an IDENTITY is too commonly thrown onto a table serving as the only unique aspect of the table. My answer to the question was based on explaining why the error message was being thrown, not on redesigning the table. In either design, I fail to see the purpose of the second table.
– Aaron Bertrand
Apr 16 '12 at 22:15
Also you've indicated the primary key constraint twice in your second table - once unnamed, once named.
– Aaron Bertrand
Apr 16 '12 at 22:18
Ah the cookie cutter auto number approach for tables that "don't have a key". Not a big fan of that myself, more of a rectangular array than a Table, that one.
– Tony Hopkinson
Apr 16 '12 at 22:21
|
show 1 more comment
up vote
0
down vote
CREATE TABLE Airplane_type
(
airplane_type_id not null Identity(1,1),
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
type VARCHAR NOT NULL,
business_capacity INT NOT NULL,
economy_capacity INT NOT NULL,
range INT NOT NULL,
weight INT NOT NULL,
length INT NOT NULL,
wingspan INT NOT NULL,
CONSTRAINT PK_AIRPLANE_TYPE PRIMARY KEY(airplane_type_id),
Constraint UK_Spotted_By_AARON Unique Key (make, model)
);
CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL,
airplane_type_id int not null CONSTRAINT FK_Airplane_AirPlane_Type
Foreign Key References(AirPlane.Airplane_type_id),
Constraint PK_Airplane Primary Key (Airplane_id),
);
Using parts of a compound key as a constraint isn't a goer a far as I know, and if you normalise, it's unnecessary. The way you had your schema an airplane with a make and model combination not in your airplane type table was valid.
How does adding an identity column and removing the key onmake,model
help anything? Now you can have duplicatemake,model
because your only unique constraint is on the meaningless identity value. At the very least you should still have a unique constraint onmake,model
or vice-versa (a foreign key constraint can reference a unique constraint in SQL Server, not just a primary key, so you can have both).
– Aaron Bertrand
Apr 16 '12 at 21:59
I'm going to take a wild guess here and predict you don't sit on the same side of the surrogate versus natural keys debate. I forgot teh unique constraint, give me a minute. Meaningless identity value is the point...
– Tony Hopkinson
Apr 16 '12 at 22:09
No I agree about surrogates I just think an IDENTITY is too commonly thrown onto a table serving as the only unique aspect of the table. My answer to the question was based on explaining why the error message was being thrown, not on redesigning the table. In either design, I fail to see the purpose of the second table.
– Aaron Bertrand
Apr 16 '12 at 22:15
Also you've indicated the primary key constraint twice in your second table - once unnamed, once named.
– Aaron Bertrand
Apr 16 '12 at 22:18
Ah the cookie cutter auto number approach for tables that "don't have a key". Not a big fan of that myself, more of a rectangular array than a Table, that one.
– Tony Hopkinson
Apr 16 '12 at 22:21
|
show 1 more comment
up vote
0
down vote
up vote
0
down vote
CREATE TABLE Airplane_type
(
airplane_type_id not null Identity(1,1),
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
type VARCHAR NOT NULL,
business_capacity INT NOT NULL,
economy_capacity INT NOT NULL,
range INT NOT NULL,
weight INT NOT NULL,
length INT NOT NULL,
wingspan INT NOT NULL,
CONSTRAINT PK_AIRPLANE_TYPE PRIMARY KEY(airplane_type_id),
Constraint UK_Spotted_By_AARON Unique Key (make, model)
);
CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL,
airplane_type_id int not null CONSTRAINT FK_Airplane_AirPlane_Type
Foreign Key References(AirPlane.Airplane_type_id),
Constraint PK_Airplane Primary Key (Airplane_id),
);
Using parts of a compound key as a constraint isn't a goer a far as I know, and if you normalise, it's unnecessary. The way you had your schema an airplane with a make and model combination not in your airplane type table was valid.
CREATE TABLE Airplane_type
(
airplane_type_id not null Identity(1,1),
make VARCHAR NOT NULL,
model VARCHAR NOT NULL,
type VARCHAR NOT NULL,
business_capacity INT NOT NULL,
economy_capacity INT NOT NULL,
range INT NOT NULL,
weight INT NOT NULL,
length INT NOT NULL,
wingspan INT NOT NULL,
CONSTRAINT PK_AIRPLANE_TYPE PRIMARY KEY(airplane_type_id),
Constraint UK_Spotted_By_AARON Unique Key (make, model)
);
CREATE TABLE Airplane
(
airplane_ID VARCHAR(3) NOT NULL,
airplane_type_id int not null CONSTRAINT FK_Airplane_AirPlane_Type
Foreign Key References(AirPlane.Airplane_type_id),
Constraint PK_Airplane Primary Key (Airplane_id),
);
Using parts of a compound key as a constraint isn't a goer a far as I know, and if you normalise, it's unnecessary. The way you had your schema an airplane with a make and model combination not in your airplane type table was valid.
edited Apr 16 '12 at 22:24
answered Apr 16 '12 at 21:58
Tony Hopkinson
18.6k32437
18.6k32437
How does adding an identity column and removing the key onmake,model
help anything? Now you can have duplicatemake,model
because your only unique constraint is on the meaningless identity value. At the very least you should still have a unique constraint onmake,model
or vice-versa (a foreign key constraint can reference a unique constraint in SQL Server, not just a primary key, so you can have both).
– Aaron Bertrand
Apr 16 '12 at 21:59
I'm going to take a wild guess here and predict you don't sit on the same side of the surrogate versus natural keys debate. I forgot teh unique constraint, give me a minute. Meaningless identity value is the point...
– Tony Hopkinson
Apr 16 '12 at 22:09
No I agree about surrogates I just think an IDENTITY is too commonly thrown onto a table serving as the only unique aspect of the table. My answer to the question was based on explaining why the error message was being thrown, not on redesigning the table. In either design, I fail to see the purpose of the second table.
– Aaron Bertrand
Apr 16 '12 at 22:15
Also you've indicated the primary key constraint twice in your second table - once unnamed, once named.
– Aaron Bertrand
Apr 16 '12 at 22:18
Ah the cookie cutter auto number approach for tables that "don't have a key". Not a big fan of that myself, more of a rectangular array than a Table, that one.
– Tony Hopkinson
Apr 16 '12 at 22:21
|
show 1 more comment
How does adding an identity column and removing the key onmake,model
help anything? Now you can have duplicatemake,model
because your only unique constraint is on the meaningless identity value. At the very least you should still have a unique constraint onmake,model
or vice-versa (a foreign key constraint can reference a unique constraint in SQL Server, not just a primary key, so you can have both).
– Aaron Bertrand
Apr 16 '12 at 21:59
I'm going to take a wild guess here and predict you don't sit on the same side of the surrogate versus natural keys debate. I forgot teh unique constraint, give me a minute. Meaningless identity value is the point...
– Tony Hopkinson
Apr 16 '12 at 22:09
No I agree about surrogates I just think an IDENTITY is too commonly thrown onto a table serving as the only unique aspect of the table. My answer to the question was based on explaining why the error message was being thrown, not on redesigning the table. In either design, I fail to see the purpose of the second table.
– Aaron Bertrand
Apr 16 '12 at 22:15
Also you've indicated the primary key constraint twice in your second table - once unnamed, once named.
– Aaron Bertrand
Apr 16 '12 at 22:18
Ah the cookie cutter auto number approach for tables that "don't have a key". Not a big fan of that myself, more of a rectangular array than a Table, that one.
– Tony Hopkinson
Apr 16 '12 at 22:21
How does adding an identity column and removing the key on
make,model
help anything? Now you can have duplicate make,model
because your only unique constraint is on the meaningless identity value. At the very least you should still have a unique constraint on make,model
or vice-versa (a foreign key constraint can reference a unique constraint in SQL Server, not just a primary key, so you can have both).– Aaron Bertrand
Apr 16 '12 at 21:59
How does adding an identity column and removing the key on
make,model
help anything? Now you can have duplicate make,model
because your only unique constraint is on the meaningless identity value. At the very least you should still have a unique constraint on make,model
or vice-versa (a foreign key constraint can reference a unique constraint in SQL Server, not just a primary key, so you can have both).– Aaron Bertrand
Apr 16 '12 at 21:59
I'm going to take a wild guess here and predict you don't sit on the same side of the surrogate versus natural keys debate. I forgot teh unique constraint, give me a minute. Meaningless identity value is the point...
– Tony Hopkinson
Apr 16 '12 at 22:09
I'm going to take a wild guess here and predict you don't sit on the same side of the surrogate versus natural keys debate. I forgot teh unique constraint, give me a minute. Meaningless identity value is the point...
– Tony Hopkinson
Apr 16 '12 at 22:09
No I agree about surrogates I just think an IDENTITY is too commonly thrown onto a table serving as the only unique aspect of the table. My answer to the question was based on explaining why the error message was being thrown, not on redesigning the table. In either design, I fail to see the purpose of the second table.
– Aaron Bertrand
Apr 16 '12 at 22:15
No I agree about surrogates I just think an IDENTITY is too commonly thrown onto a table serving as the only unique aspect of the table. My answer to the question was based on explaining why the error message was being thrown, not on redesigning the table. In either design, I fail to see the purpose of the second table.
– Aaron Bertrand
Apr 16 '12 at 22:15
Also you've indicated the primary key constraint twice in your second table - once unnamed, once named.
– Aaron Bertrand
Apr 16 '12 at 22:18
Also you've indicated the primary key constraint twice in your second table - once unnamed, once named.
– Aaron Bertrand
Apr 16 '12 at 22:18
Ah the cookie cutter auto number approach for tables that "don't have a key". Not a big fan of that myself, more of a rectangular array than a Table, that one.
– Tony Hopkinson
Apr 16 '12 at 22:21
Ah the cookie cutter auto number approach for tables that "don't have a key". Not a big fan of that myself, more of a rectangular array than a Table, that one.
– Tony Hopkinson
Apr 16 '12 at 22:21
|
show 1 more comment
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f10182170%2fcant-create-foreign-key-using-individual-columns-against-multiple-column-primar%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown