>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".
>
>VFP3 introduced the View with optimistic locking as its default state and change tracking by default. It worked well and eliminated all the rlock() code and contention management. IOW there was less code, not more.

True, and was it VFP 5 or 6 that introduced transaction/rollback, which made the task even easier. However, optimistic locking still could wreak havock with the default "last save wins" -behavior. A good example given above by Kevin (I think) where one person edits the city and zip code and another one only the zip code. Now the guy editing the city and the zip code saves, then comes the guy editing the zip code only and saves. you now have a "semantic disconnect" between the city and the zip code, which would be hard to catch by the software, unless it compared city/zip code tables during validation. This is not a very likely real-life scenario, but it points out the pitfalls in optimistic locking and field-to-field dependencies.

Also, some field integrity issues can arise from straight updates that bypass the Business Object. For example, you might have a business rule which states that "a person marked as RETIRED must be OVER 60 YEARS OLD" (again, this is a very simple and probably not very likely real-life scenario). If one guy changes the RETIRED flag to TRUE and saves while another guy is correcting the age from 60 to 59 and saves, you have a business rule validation problem on the record level. Jeff Pace brought up a good point about this, which I have been thinking about as well, that this discussion should probably involve change tracking through the BO.

>
>The second issue was the rise of the stateless application, such as a web app. Consensus was (and is) that pessimistic locking is infeasible in these circumstances.

Yes, that's the consensus, and for many good reasons. Yet, you don't have to go with the consensus if it doesn't fit your clients' needs...

>
>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.
>
>Sounds dire. Can you provide an example? I cannot think of a RI problem caused by selective updates, as long as the standard principles are followed: system-generated primary keys that cannot be edited, triggers if changes need to cascade and transactions if work needs to be done that doesn't fit in a trigger.

True, and I personally never use compound or natural keys. I was just thinking of situations where someone might use natural keys, or situations where business rules cover data from multiple tables, which, strictly speaking, is not an RI problem...

>
>I know that optimistic locking and the resulting programming mess is sometimes a necessity...
>
>What programming mess would that be? If you update edited fields using a where clause consisting of the primary key, your chance of success is as good as can be. If you use VFP Views, that was done for you automatically. I can understand why you might see a mess if you used compound or human-editable keys... but that's a separate issue.

It is a mess when there is a lot of validation interaction between data items within one or more tables. Again, running change tracking through a BO could take care of this, but the error message to the last saver as to what is wrong with his save -attempt could get way too verbose for a regular data entry person to comprehend. Such as, "Record can not be saved because a person marked RETIRED must be OVER 60 YEARS OLD." The dude would look at his screen and say:"Heck with that, I haven't marked this guy as RETIRED, I can see it right here on the screen in front of me! This software stinks. Call tech support!" So, you would have to expand on the error message so that it says something like:"While you were editing this record, another user changed this person's RETIRED status as retired. You are trying to save a change in age from 60 to 59. This would make the person RETIRED at 60 YEARS OLD, which is not allowed!" Now multiply this logic by the number of interrelated data items on your record,and it does become a mess...

Just sayin'...