Tami - would it not be a good idea to stick to 'best practices' when using linq and add a autonumber primary key, even if it isn't going to be used other than for inserts or updates?? i can think of many instances where the seemingly 'non requirement' for a primary key later leads to trouble when trying to update to other platforms etc.
If there's a compelling reason to not add a 'blind' primary key, then it might help to detail this as well in the question. I can't think of any reasons not to add it, especially if it means that you don't have to code around the limitation.
jim
[edit]
Tami - i'll be honest with you. you might have to investigate conventions to best satisfy any answer to this question. basically, altho' you don't 'need' an index on your records, due to not being edited or deleted, the convention with linq is based around the assumption of data integrity. in essence, linq (and many other programatic tools) require a convention that allows them to succinctly identify a unique key on each object that they bring into scope. by not defining this, you are by-passing this convention and therefore linq is flagging this up for you. the only way fwd is to go with the flow. even if you 'feel' that the index is redundant, linq requires it to allow you to access the full functionality built into it.