>>>>You bring up a question in my mind that I've had for awhile. Are there any *real* benefits to using unique or candidate keys. I've yet to come up with anything that outweighs the annoyances.< s >
>>>
>>>Absolutely there are. To name two (and there are others) that apply to VFP:
>>>
>>>1) Normalization. You need a unique key that will never change.
>>>2) Scalability. SQL Server and Oracle DEMAND unique, primary keys.
>>>3) Conflict. A unique violation may alert you to other errors in data mgmt.
>>
>>
>>Of course there is a need for a unique key, but what is the need for an index that is of type Primary or Candidate when a regular index will do just as well (and allow me control to fix problems that should arise like the start of this thread)? < s >
>
>Hmmm...I'd have to think about that....my gut instinct is to respond "are you nuts??" but that is high-tower database theory talking (just kidding). A unique key identified as the Primary key is a central tenet to relational theory. You don't HAVE to have one in VFP standalone if you really don't want to...

Primary/canidate key is ultimate way to prevent duplicate records. Multi-user system cannot rely just on some search before e.g. adding new record, just because it's always possible that another user does the same thing at the same time, i.e. both will get successful search (no duplicates) and then add the records with duplicate values.