Exactly, your current PK should be a canidate key. That way it will enforce uniqueness but the new integer PK will be the key for updating data. Since the canidate key will not be used for updating or joins with other tables the NOT DELETED() will not effect performance.

>So you believe that a integer primary key would be better and then the actual PK would be a candidate key.
>
>Jason
>
>
>>I agree with David's comments about the primary key. You really need to change it.
>>
>>The slow update is mainly due to the NOT DELETED() in the index. Using NOT DELETED() is a huge performance killer with TABLEUPDATE(). Since your primary key is made up of user entered data you must have the NOT DELETED() filter. This in another reason to use an application-generated, meaningless, integer field for a primary key.
>>
>>>13 fields, length 105.
>>>
>>>TRying to update 7000 records.