One of the many topics I cover in my ADO.NET 2.0 talk is about the ability to
modify the rowstate of unchanged rows with SetAdded or SetModified. If you have
never been in a position where you wished like crazy that you could change the
row state, or if you don't understand the semantics of DataRowState and how
importing, adding or merging affects it, then these features don't really make a
lot of sense.
Moving datarows around is not the only time I imagine you might have a need
to affect the rowstate, but I wanted to just point out a few of the nuances of
moving rows.
When you add rows using the DataTable.Rows.Add method, the
rowstate of the added row will be Added (regardless of what
its' original state was).
When you import a row, the row's current state will be
imported with it.
Merge is the same as import in regards to the affect on
rowstate. Merge just imports a whole bunch of rows at once. So, it, too,
persists the row state.
In the demo I have for SetAdded and SetModified, I have two sets of data. One
dataset coming from a local database and another coming form a web service. I
append the 2nd set of data to the first using the Merge function. Then the next
step is to update my database and I want the newly merged data to go in the
database as well as any changes to the original set of data. In the demo, all of
those new rows from the web service do not get uploaded because their
rowstate was "Unchanged". By using the Merge function, the rows were not flagged
as "Added". This definitely is a surprise to some people when I do that demo
because many do not grok the differences between Import/Merge and Add.
Here is a Data Points
column by Joseph Papa from a 2003 issue of MSDN Magazine that explains how
rowstate is affected. After reading that, it might make more sense why having
the ability to affect the state of the rows is a useful thing. SetAdded and
SetModified are two functions that you do not want to use unless you definitely
know what you are doing.
www.acehaid.org