>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 ??

DataAccess class of course ... is that what you meant? DataSets, IMHO, should know nothing about where its data comes from ... likewise the DataSet should know nothing about how to save itself to the database.

>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.

That, of course, varies depending on the application. In our case, we save every field in a changed row, so the last one to save wins ... but in this particular market, there will almost never be two different people working on the same records (this is a fire department records management system), so it doesn't matter. As I've mentioned before somewhere, creating a field-level change tracking mechanism is a relatively trivial endeavor.

>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!

No, that's probably not do-able for us without massive changes to our architecture which we're not going to do. The main reason is that we simply pass the changed data back (as an XML string) through a Web Service method rather than passing the DataSet itself (which keeps track of the changes and thus you'd have Original and Current versions).

So, at the UI level your DataSet has Original/Current versions, but not server-side:

// UI
DataSet dsChanged = MyDataSet.GetChanges();
DataSet dsDeleted = MyDataSet.GetChanges(DataRowState.Deleted);
string XML = dsChanged.GetXml();
string XMLDeleted = dsDeleted.GetXml();
MyWebService.SaveMyData(XML, XMLDeleted);

~~Bonnie