>>Pessimistic setting is really difficult to control and better be simulated by RLOCK(). Normally, row optimistic buffering with trap on soft TABLEUPDATE() will work Ok.
>
>Hi Ed,
>
>The only drawback that I can see with simulating it with RLOCK() is that you're going to have to code to establish the lock prior to beginning editing (toolbar button, etc.) I personally don't think it'd be as intuitive to the user. It becomes a balancing act then between ease of use and creating and maintaing the code. I think strictly a matter of preference by the developer.
Agreed with one exception that RLOCK() in unbound interface will not require particular entry point like cmdEdit.click. In a case of pessimistic buffering developer actually doesn't know exactly where the actual lock happened and it might be not good.
Edward Pikman
Independent Consultant