Michel,

Assuming that you are certain that this is the code in question, then I would conclude the following:
1) the record being obtained *IS* locked by some other process
2) That process is holding the record for a long time (permanently?)

It is hard to say, but it is possible that the message is actually coming from the REPLACE command - if the record is long-term locked by something, then the RLOCK will be tried a total of 20 times and then you will do the REPLACE anyhow.

Good luck
Jim N.
>>Could you be getting into a "deadly embrace" situation? - that is when, for example, PC-A has a lock on record x and wants to lock record y AND PC-B (already) has a lock on record y and wants to lock record x.
>
>I have two instances of the EXE running on the server.
>
>As for instance A mixing with instance B, I don't know where in the system I can have this situation.
>
>>One can normally devise strategies to get around this, though it can get hairy in some cases.
>
>Since this is a non interface EXE and it's only one process at a time, the only place where I check for locking is when I increment my primary keys. This is the code I use for the mecanism of making sure EXE A will wait until EXE B finish when a collision occurs in the primary key calculation.
>
>
>FUNCTION GetNumero
>* Get the next id
>* expC1 Name of the table in TABLE.DBF
>PARAMETER tcTable
>PRIVATE lnOldSel,lnNext
>LOCAL lnCompteur
>lnOldSel=SELECT()
>SELECT TABLE
>LOCATE FOR TABLE=tcTable
>SET REPROCESS TO 2
>FOR lnCompteur=1 TO 10
> IF RLOCK()
> EXIT
> ENDIF
>NEXT
>REPLACE NUMERO WITH NUMERO+1
>UNLOCK
>lnNext=NUMERO
>SELECT(lnOldSel)
>RETURN lnNext
>