I may be missing something, but....
if you're adding records pessimistic record locking makes no sense
because the records are added to that user's buffer and not to
the table until a tableupdate() is requested.

the editing records pessimistically makes sense, but i'd tend toward
using the pessimistic record locking (cursorsetprop('buffering',2))
instead of the pessimistic table locking.

>Reality check:
>>If User #1 sets pessimistic record locking on a table and
>does an APPEND BLANK, the table header gets locked. This prevents others from doing an APPEND BLANK until User #1
>does a TABLEREVERT()/TABLEUPDATE(), which is clearly unacceptable in a multiuser situation.
>>However, if User #1 sets optimistic record locking on a table and then does an APPEND BLANK followed by an RLOCK(), other users *can* successfully do their own APPEND BLANKS.
>>So it would it seem that the only real way to implement a
>pessimistic row locking strategy using record buffering is
>to use *optimistic* buffering in conjunction with explicit
>locking via RLOCK().
>>Is my conclusion correct? This approach on the face of it
>seems to be fairly subtle and not something that most developers would be likely to stumble on without a good deal of thrashing around.