>I have a case where a user can be modifying a record and another user runs an app and copies the record anyway. Example. My usewr is in there editing record number 14. They have not hit save yet. Another user runs an app and record 14 applies to what they want so the app copies the record to another table. The app should then go back and delete the record in the previous table but does not. I thought I had pessimistic choosen as a whoe in my preferences but maybe Iam missing something. The result we have now is that the record in in both tables and can be accidently edited and sent out again. Any wayb to assure that if a user is using a record that another app or person can't come along and get it?
>
>Thanks in advance for your help. Happy holidays.
>
>Randall

Sounds like the system is working "as designed" :-) Even if User 1 has record 14 locked with pessimistic buffering (assuming that's set up correctly), user 2 can still read that record (as you've found). However, user 1 has it locked, so user 2 is not able to delete it.

Another approach is to not use pessimistic buffering. In that case, user 2 *would* be able to delete the record. When user 1 goes to save changes, the update routine would have to check for the existence of the record; if not found, the user should get back a messagebox saying "Whoops! Someone else deleted this record! Can't Save" or words to that effect.