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
>
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only