Jim,

Thanks for the clarification. Just to be sure I'm understanding is there no easy way then to distinguish if the underlying record is DELETED() or the implicit lock fails during the TABLEUPDATE()? Simply relying on tableupdate() returning .F. doesn't seem to permit much helpful intervention.

>Jim,
>
>There is no easy way to do pessimistic strategy using views. Views are naturally optimistic. Even if you wrote the code to locate the record in the original file and lock it, that approach would fail miserably if you ever changed to C/S data sources.
>
>To implement the idea you would need to use the PK(s) in the view to locate the record in the original table(s) and secure locks on them. If you chose to do this generically you would making heavy use of DBGetProp and CursorGetProp to find out what the PK(s) and Table(s) are and then finding the records and locking them.