Russel

The two aren't mutually exclusive. Of course it's a good idea to buffer your data, and TableUpdate() when you want to save. If any TableUpdate() should fail then you can ROLLBACK rather than END TRANS.

You can use Optimistic table locking (5), for multiple rec updates, which doesn't actually lock the table, and the updated recs, until
TableUpdate(), so the table's still available for other users. However, I'd use this, say, when scanning through a table and updating several recs one after the other. But if there's a human delay and the user is picking each rec then row buffering (3) might be more appropriate.

Example:

BEGIN TRANSACTION
llSuccess          = .T.
llStillUpdating    = .T.
Do while llStillUpdating and llSuccess
  {access a rec and edit it and then choose save}
  llSuccess        = TABLEUPDATE(.T.)
  If llSuccess
      {Do other stuff}
      {When finished, llStillUpdating gets set to .F.}
  EndIf
EndDo
If llSuccess    && i.e. every update has been successful, up to the last
    END TRANSACTION
Else
    ROLLBACK
EndIf

HTH

Terry

>I have a single DBF, where several records need to be updated independent of the rest of the database. However if all records are not updated successfully, then I need to revert the all changes.
>I can achieve this with BEGIN TRANSACTION ... END TRANSACTION or with Table Buffering.
>Which alternative is recommended and what is faster?
>Note that ideally, I do not want to lock the table during this process.