>>>I tested your idea. 50 iterations of rlock() using set reprocess to 1 took about 17 seconds. 50 iterations of rlock() using set reprocess to 0 seconds took about 4 hundreths of a second. Thanks so much for your help.

>>Well, that's nice, but kind of beats the idea of reprocessing - IMO, it _should_ wait some time to give the other processes some time to unlock the record. With 50 retries in 0.04 seconds, you have hit the network with 50 lock requests, and gave the process which kept the lock very little chance to release it.

>The test I did was only to see if there was a difference in speed, that I could use as a confirmation that SET REPROCESS TO 0 SECONDS was in fact not trying a second rlock() after the initial attempt. My intent is to issue an rlock() and give up as quickly as possible if it returns .f., not to try a second (or 50th) time.
>
>I'm working with a system that can have VERY high contention for extended periods of time. SET REPROCESS TO AUTOMATIC was causing a problem when several processes were going after the same record during an attempt to recycle deleted records. As you suggest, constant pounding can cause things to slow down. My solution is to randomly select a deleted record (more than 95% of all the records are deleted), attempt a lock, and if .f., try another random choice.

In this layout, it really makes sense. When I think further, it's just a very smart strategy. I'm just wondering how do you find a random deleted record? I guess it's something like
Set Order to Deleted
Seek .t.
count next rand()*100 while deleted()
if deleted()
do your_thing
...etc

Or you've come up with something better?

>I've seen you do a search in memo fields before that seemed to turn the normal rules inside out to get both speed and accuracy, so I know you will appreciate giving up to get more speed.

Ummm... which one do you mean? The only thing I remember I was doing a memo search on is when I was extracting keywords into an additional table.