>>>
>>>You could use following solution:
>>>1. You have candidate index (no filter).
>>>2. When you try to save a record and trap duplicate key error, you can check >deleted() status of the existing record and, if deleted=.t., recycle it.
>>
>>Thanks, Edward. I tried that approach and here some of my thoughts:
>>
>>1. This works only with views. When I used table (ether with record or table buffering) I couldn't move record pointer to check if the record with the same field value is deleted. The error "The uniqueness of ...bla,bla,bla violated" occured when I tried to do that.

to check this way, use the table AGAIN in another work space and check there...

>>
>>2. What if user doesn't add a record but changes the existing one? How do I recycle the deleted record? I tried to REPLACE the unique field of the deleted record with the STR(primary key)(I use surrogate Integer keys) of that record, assuming that the field is a string and user can't put numbers in it. So the value would be unique.But it won't work with numeric fields.
>>
>>Thanks, again.
>
>Didn't you know that I don't use buffering? BTW, VFP6 will have function allowing SEEKing without moving pointer. In regard to second problem: it's not difficult to have routine finding new 'unique' key value to shift out deleted record. BTW, the normal process could also involve 'safe deletion': when you delete a record, candidate key values get replaced by some reserved sequence (e.g. "000001","000002", etc.).
>
>Privet Sevastopolyu.