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.