Kevin, we've had this discussion here before if you want to check past threads ;-)

It was common in VFP to use the inbuilt change tracking to allow users to edit SQL Server records simultaneously without fault unless they both edit the same field, in which case you can prompt the second saver for a decision. VFP handled the contention stuff completely.

A lot of those who moved away from Fox around here use SPs that update every field, meaning they don't worry about change management at all. "Whoever saves last wins" is their stated goal. Several have commented that even though there is a risk that (for example) a new postal address might be overwritten because somebody else wanted to change the customer from "Mrs" to "Ms" at the same time, this is rare enough that it is not an issue.

Those who do use change tracking have described a semaphore mechanism in which there is a separate table in which you create a record to "lock" the record you are working on. When somebody else tries to edit the same row, your app checks the semaphore table and warns them off. These developers also describe writing a "lunch lock" mechanism to regularly unlock records that have been left locked for too long.

This semaphore mechanism is favored by its proponents for situations where you absolutely must prevent simultaneous change of a record or set of records. Stated examples include insurance, financial or stock systems. Apparently this need is different from using transactions, fwiw.

Problems do arise if you predict one or more users/processes needing to edit different parts of the same record at once. Semaphore holdup is not suitable in a customer-facing situation. Perhaps this would be a good role for traditional change tracking in which neither user need be affected by the separate actions of the other. Either that or you can break your table into multiple tables to reduce the chance of contention, but many of us have established systems or tables required by others that cannot be changed in this fashion- and it's a big job if there are other ways.

In NET you can use typed datasets to pass change tracking around with your data. Kevin Goff posted some SP code that can be combined with Typed Datasets to manage change management by sending NULL to your SP for any field that is not changed. He also posted a mod to allow NULL values to SQL Server datetime fields. I have not tried this in real life and I'm not sure whether he has either, but he can update us on that.

Finally, Linq to SQL can handle change management for you automatically as long as you use a 2-tier system. If you need to pass data between disconnected layers, the ability is completely lost. I'd also note that L2S has been "Foxed" by MS meaning you may want to think carefully about writing new stuff using it. I have no doubt you could achieve the same using the EF, but once you start to try you may decide not to proceed. ;-)

HTH