>No, it works. Unfortunately (IMHO). Sorta. However, if you have a candidate key, then that also needs on index on unique.
>
>There are times, though that you will still get uniqueness violation if you go back and try to recall the record to reuse it. Surrogate keys is much, much, much, much easier to program and maintain. Much. Even to retrofit surrogate keys in tables isn't really all that bad. Updating the relationships or joins between tables is tedious, but the time you save in having to mess around with quasi-unique primary keys is well worth it. Not that I'm biased, or anything! < s >
>
>
>>>Yes, you can: filter your primary key index on NOT DELETED(), and deleted records won't bother you. However, this has a drawback; since filtered indices won't be used by Rushmore, you will need to add a regular index on the same expression, so your queries can be optimised.
>>>
>>Uhhh! Are you sure about this? My experience is that a deleted record still will not permit a new record with the same primary key to be added to the table irrespective of SET DELETED status.

Hi Nancy,

Frankly I have never figured out the purpose of surrogate primary keys. If you need a unique data order, a primary key is the way to go. If you don't need it, then stick with regular indices -- which are a lot easier to work with.

I suspect I don't fully understand their (surrogate keys) utility. I'll have to get one of the wunderkinder to explain it to me sometime.

Best wishes for a happy and successful new year,

regards,