I've used pessimistic locking (with a transaction timeout) in my VFP accounting apps for years and years, and the users really appreciate the fact that they know they own the record(s)/row(s) they are working on while they are working on it/them (unless they leave the record locked and go to lunch, in which case their current session will time out and the transaction will roll back and the application will shut down in a controlled way, with a note to the the miscreant about what happened and why that pops up when they log in the next time).

The whole change/update tracking got to be such a headache for me at some point that I decided to implement pessimistic locking in all of my apps (thousands of them), and so far noboby has complained. Quite on the contrary -- as long as the users have enough information about who has the record locked and how long it has been locked and how to reach them, the users are fine about bugging each other to "get off my record".

If you must allow simultaneous access due to some time-critical and update-conflict-prone data, then you need to implement granular, column -level rules about inter-relations between data items and potential RI problems between related tables if you plan to allow a partial (or selective) update on top of a previous update. Not a good candidate for a generic solution, that.

I know that optimistic locking and the resulting programming mess is sometimes a necessity, but so far I have been able to talk my customers out of it except for a few isolated situations. And in those cases I developed a 10-Aspirin headache... And this while using VFP, which gives you a ton of information about the state of your data before, during and after the transaction, locally and remotely. I imagine I will need additional 10 Aspirins if/when I have to do this with .NET... So far so good, though, and I will stay optimistic about being able to continue using pessimistic locking as I slowly move my VFP apps over to .NET.





Pertti


> Just curious- what sort of customer demands pessimistic locking?
>
>Insurance company...(actually, I just thought of a second one, for an e-commerce client)