>Walter,

>I see exactly where you are coming from. It really is the 10-90 -rule, where the last 10% of completing an application can take 90% of the total time. If people's lives are not on the line because of potential validation holes you can, and it is even prudent to, make some reasonable allowances. So, if you are not programming the space shuttle or jumbo jets' autopilot systems, you can relax a little.

Indeed it is economics. Also its a very difficult topic because you tend to do too little prevention and have to deal with the consequences ad-hoc. It is a part of getting software matured.

>Part of pessimistic locking strategies for me is to lock ALL related records as well, so that nothing falls through the cracks. And this works with 100% accuracy without me having to think of all of the possible ways concurrent data entry can mess up the data.

Ouch that would not work for us. In a given form there could as many as 30 tables involved. There is no way we can use pessimistic locking as it would severely impairs multiuser capabilities and that is not good for a clinic management system that is designed to be used for 20 - 50 concurrent users.

>Again, not ideal for many reasons, but I go pessimistic whenever I can get away with it.

We use however pessimistic locking for one specific instance. Like martin mentioned, not really on a table level, but lockng functionality. We make sure that only one user can enter a specific patients financial records at the time, and create invoices.

Walter,