>Marc,
> You can't rlock() buffered data. By setting the buffering to 5 (or 3) your getting optimistic buffering, which means the record/s are not getting locked in the table while they are edited, VFP will lock them when you call tableupdate() though, which means anybody can edit the records while you are editing them.
>If you set buffering to 2 - pessimistic record buffering or 4 - pessimistic table buffering the records will be buffered and they will be locked in the table for you so nobody else can modify them while you are editing. If you set buffering to 4 the header of the table will be locked which means nobody else can edit any records in the table while its locked. The whole point of buffering is so you don't have to manually use rlock() VFP does it for you. Hope this helps.
>
>Mark

Mark,

Your assessment of buffering is correct....but, this app needs to inform the
2nd user retrieving a record that another user is editing that record and is already in use by another. This app is also mapping class properties and the controls are not bound to tables or views directly which means that pessimistic buffering, which starts when a user actually edits a record, will not get recorded either because the table will not pick up the change until an actual update occurs.

And, if you follow the entire thread regarding my problems with rlock(), you'll note that my original issue was with rlock() returning .T. when the tables were not buffered at all. I've since put in 2 - pessimistic, but it's still not recording a lock. Buffered/unbuffered, each user is getting a .T. returned from rlock().

Steve