This post may seem a little old-fashioned nowadays, considering that most developers are looking at WPF and binding to objects rather than the good ol' DataSet, but I found out about this only today and I can see a few projects in my future where it could come in handy.

Y'know how the DataSet class has a couple of methods (WriteXml and ReadXml) for persisting its data to disk?

Did you know that it's possible to preserve any pending changes when you stream the data to XML?

WriteXml has an overload which takes an XmlWriteMode enum as its second parameter. If you pass XmlWriteMode.DiffGram to that, the DataSet gets written to XML in such a way that any added, deleted or modified rows have their changes persisted to the file. Similarly, ReadXml has an overload that takes an XmlReadMode enum, to which you can pass XmlReadMode.DiffGram to read the DataSet back in with its pending changes intact!

Even better: If your tables have a primary key defined, the ReadXml method will perform a smart merge of the data, meaning that you can read in only the changed rows and it'll affect those rows only in your tables, flagging them as inserted, deleted or modified. The reason this is handy is that you can save only the changed rows to XML by first calling DataSet.GetChanges(), and then saving the resulting DataSet to XML instead of the original!

So if you have an application that needs to go offline, but still keep track of changes to data so that when the user reconnects you can upload those changes to your server, this would be a great solution. SQL Server 2005 Compact Edition is another solution (and the one I was originally looking into) but setting up the replication etc is a bit complex for the project in question.

DataSets, eh? They never fail to surprise.