We pass DataSets around (or as an XML string through the Web Service layer, although not as a DiffGram) ... we use GetChanges() to only pass the changed stuff back through the Web Service to the DataAccess, so that only changed rows get updated.

Cool! So where do you keep the update code- in a partial class for the DataSet or ??

Up until now, we haven't had to worry about using any kind of locking mechanism ... the nature of our application was such that it was good enough that when changes were saved, the last one saved was the winner.

I think that's fair enough- if 2 users edit the same field at once, most often it'll be reasonable to accept both saves (as long as that's all you save- i.e. you don't save every field.) IMHO change tracking with this principle is not more difficult than rolling your own pessimistic locking and saving every field every time.

Now however, with some new apps we're in the process of developing, we *are* going to have to worry about it. We are planning on implementing semaphore locking, but haven't gotten that far into it yet.

Could you avoid locking by crafting a SQL update whose WHERE clause specifies the original values of critical fields that have been edited? Then the update will fail if a critical field has been edited by another user, in which case you can pull newer values and get the user to adjudicate. I suppose it depends on whether the customer wants the second user to adjudicate or whether they're happy to queue edits. If you do queue, once user1 finishes, IMHO user2 is going to go right ahead and edit the fields they want whether user1 edited them or not, so you might as well let them both get on with it!