>>.......................
>>Excellent! I've got to get more adventurous ... I let the help file stop me when it said that the value for seconds must be greater than 0.
>>
>>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.
>>
>>Bob
>
>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.

Dragan

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.

To make this work, I needed a method to turn off reprocessing so that rlock() would try ONLY once, not twice as SET REPROCESS TO 1 would have done. I still use 'normal' reprocessing in all areas except recycling records.

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.

Bob