>Optimistic buffering allows many different users on many different workstations access to the same table. And when you are getting ready to update the record(s) it must attempt at that time to get the record lock to prevent other users from updating at the same time. You are locking the actual data. You are not opening the table exclusively.

I know I'm not opening the _table_ exclusively. What I said was, isn't the buffer a _cursor_, which in fact only exists in my workstation's memory? I know that when I issue TABLEUPDATE(), VFP tries to lock the real records in order to update them.

I was getting "Record not locked" when trying to do a REPLACE command on a record in the buffer, _before_ the TABLEUPDATE command. The REPLACE command, operating on a buffered record, shouldn't require any "lock," right? The locking attempt should have occured when I issued TABLEUPDATE() a few commands later.

Still confused,
Rich.