>>>>Like most of us, I'm sure, we have times when we need to lock a large number of records at one time. In this case we need to mark over 100 records before batching them.
>>>>
>>>>On a whim we just tried this SQL statement and darned if it didn't work. This is all VFP 9 by the way, both code and .DBF.
>>>>
>>>>My question is this, has anyone else used this (I have never seen it before) and what what are the odds that it can always be relied on to work? It just seems to be too easy.
>>>>
>>>>

SET MULTILOCKS ON
>>>>
>>>>select k_arinvc, rlock('arinvc') as lockok ;
>>>>from arinvc ;
>>>>where duedt > {^2007-02-01} ;
>>>>into cursor c_locks
>>>>
>>>>brow

>>>
>>>Select-SQL itself doesn't lock records. Using Rlock() function inside it looks very unreliable.
>>
>>Edward, you are right that the SQL is not locking the records. However, since the rlock() function is apparently working ok and returning .T. or .F. then I think it might be ok.
>
>That's exactly what I meant: it might be Ok, or it might be not. Using work area oriented UDF in Select-SQL is not reliable. I understand that it is the same work area for us (i.e. outisders), but internally VFP may create some temp. cursors switching areas and your RLOCK() may confuse it. You could do the same by plain SEEK/SCAN.

Edward,
I'm glad you keep challenging this. It makes me think more deeply about it. My thought on your comment about UDF is that the rlock() function is not a User Defined Function (UDF), it is a built in VFP function that is working directly on the table. Anyway, after trying it in a few more prgs it we have not found any problems, yet.