>> if ldeleted and rlock() && lDeleted = .t.)
>> if ldeleted && It didn't changed while we were getting
>> lnReturnedRecNo = recno() && the lock so we will send back it's
>> exit && record # for recycling.
>> else
>> unlock record recno() && unlock JUST this one (It was lDeleted, but
>> endif && by the time we got the lock, it wasn't!)
>> endif
>
>>It must really be crowdy at his network if between the first line and the end of the second line someone else may update the record. I'm just wandering what would I do if I had such a situation... I know! I'd search back for this thread :)
>
>Dragan
>Glad you noticed that one last check. It may be required only on a theoretical level but I was getting some index corruption that seemed to be related to the recycling of records, so I wanted to make sure there wern't any gaps on my side when I started testing. We can never be sure when windows might terminate our time slice and give control to another process.
>
>I hear you ask in advance what the solution was to the index corruption ... Well I can't actually prove anything yet, but it appeared that my problem went away when I turned on buffering (type 3, but it shouldn't matter). As with the above, the corruption only showed up during VERY HIGH contention ... lets say 50 hits per second against the same table spread over 6 processes for example.
>
>Bob

I wanted to ask what was the cause (if you ever found it - it may be yet another analysis/paralysis situation), but from your solution it seems to be that buffering (i.e. TableUpdate()ing) actually employs some better techniques than simple Replace or Gather may do. Good thing to remember, may save our necks some day.