Dick,

Yes, I believe that the update conflict is the only way to get this information in a reliable way. There is no conflict until and update is attempted. I see this the same as the old issue of telling whether you can lock a record or not, the only way to tell for sure was to lock it and see if you succeeded.

The same is true here, you need to start the transaction, issue the tableupdates and check for the return values. If one tableupdate fails then you need to roll back and table revert.

Haphazardly recalling records deleted from another station is not the best thing in the world to do. How does your code know that the record should not be deleted? What if the session doing the edit is the one with the wrong data? Should not the user in session 1 be told that some other session ahs deleted records out from underneath them? What about scaling up to client server where the ONLY way to know is to fire the update and get the return from the server.