Did you test the code in Query Analyzer to see if you get the same
message?
[quoted text, click to view] > There's a Primary Key on the SQL server only on the ID field (there is no
> need for more than one PK here as this is a simple table, i.e. ID,
> FirstName, Surname, Phone)
That's plain wrong. The artificial key should not be the only key of
any table. In Access you can get away with this because Access allows
lots of non set-based operations which work on the insertion order
preserved in the table. That's not the case in SQL Server. There are
plenty of scenarios where this kind of flaw undermines integrity and
defeats any feasible solution or at least makes it extremely difficult
to get correct results out of your data.
In your table, why would you want to have multiple rows with the same
firstname, surname and phone number? If you don't want that to happen
then it pays to create the additional key. What's a "simple" table
after all? Isn't the integrity of ALL your data important to you?
In general do not assume a schema design from an Access application
will work in SQL. You should review the design before you port it.
Hope this helps.
--
David Portas
SQL Server MVP
--