>I am trying to maintain some existing code written in FP 2.6. The program uses rlock() and unlock. I think I see a potential bug but I am not familiar enough with using rlock() to know for sure. Here is what is happening:
>
>SELECT A
>USE claims
>SELECT B
>USE cumtotals
>....Get various input
>SELECT A
>IF rlock()
> REPLACE *fields*WITH *variables*
>ELSE
> wait window "Lock failed try again"
> UNLOCK
> LOOP
>ENDIF
>SELECT B
>REPLACE "fields* WITH *variables*
>UNLOCK
>
>It seems to me that there should be an UNLOCK right before SELECT B, and then another rlock() before REPLACE fields in B. Also, does the LOOP command retry the rlock or where does it go?

Basically, you are right, any RLOCK() should be followed by UNLOCK. However, in regard to this particular code, one can say that RLOCK() is not necessary at all, and REPLACE command implicit lock will be handled by SET REPROCESS TO AUTOMATIC. It might be the case, however, that record in A has been locked in data-entry form (in other part of app) by another user. Then using of RLOCK() is understandable, and otherwise if B record cannot be locked by data-entry form, then RLOCK() for B is unnecessary.