yes, if you lock a record in a tablebuffered table, the record is locked. To test you have to open 2 instances of VFP. For this to work you have to have SET MULTILOCKS ON with TableBuffering, then you can at least use something like:

local llRetVal, lnRetVal
llRetVal = .f.
lnRetVal = GetNextModified(0)
do while lnRetVal > 0
   llRetVal = rlock()
   if not llRetVal
      exit
   endif
   lnRetVal = GetNextModified(lnRetVal)
enddo
if not llRetVal
   tablerevert(.t.)
else
   tableupdate(.t.,.t.)
endif

>Friends:
>
>I want to process a table where selected records are updated. I only want to process the records if I can get a lock on all of the qualifying "candidate" records.
>
>So, I could lock every qualifying record and then, go back to each one and update it - sort of two passes on the same records.
>
>Or, I reason that I could set buffering on for the table, go to each record and attempt to lock it. If I get a lock, update the record and move to the next qualifying record, lock it, update it and so on.
>
>If I am unable to get a lock, I could abandon the update, TableRevert() and come back to the process later.
>
>The real question(s) are therefore as follows :-
>
>Does applying a record lock to a record in a buffered table actually truly lock the underlying source table/record (in otherwords, the buffering doesn't somehow negate the lock) ?
>
>From a "best practices" POV, are you better to :-
>
>A) LOCK all candidate records first and THEN process all of the locked records.
>
>or...
>
>B) Buffer the table and individually lock/process each candidate record in sequence (or abort the whole job when a record lock cannot be achieved) and depending on a success flag, TableUpdate() or TableRevert() the buffered data.
>
>I am taking about a "free table" updated from a processing program. There is no View involved and this operation is running in a SESSION CLASS subclass.
>
>Any advice would be very much appreciated.