Martin,

>For most systems I worked for, either the "last one wins" or the "someone else updated this first, you failed" approach works ok because the chance of conflicting updates on a single row are very small, and in these few cases consistency is preferred.

>That been said, of course there is a LOT of update operations outside of the standard CRUDs that can be constrained to a few specific fields but these should be acid in themselves (no change tracking applicable), like updating shipper code and shipping time, begin/end times for processes, stock quantities, price changes and so on.

Another example is an item table that contains redundant columns for stock tracking. If a user changes description of an item, while someone of generating packing lists of order, you don't want the redundant columns to be reset to the value of what goes with the description change. We as VFP developers have been very comfortable thinking in the being very flexible in update management. Even with REMOTE and LOCAL views we remained to have this flexibility. I hate to throw this overboard as it really affects database and application design, which should be your last resort.

IOW, if I'm going to write an application in .NET, I'll definately search to the way we handle updates within VFP: "Last save wins" or "User changed a field before you" on a FIELD level rather than ROW level. The latter causes too much pain for the way database development is supposed to be done.

>Something interesting about the Entity Framework is that when updating complex entities which map to several related tables in a highly normalized schema, like updating a customer shipping address from the Customer main form, even if the update is done at the Customer entity level, will end up updating (for example) the Addresses table only, and not other tables involved, so the application wouldn't be sending lots of unneeded data to the server.

Not sure whether this applies, but only very few applications will normalise beyond 3rd NF -Boyce codd. If you go beyond that, it often does not perform well enough and is PITA is many aspects of database application developement. I'd never reccomend to go beyong 3rd NF unless there is a very convincing reason to do so.

Walter,