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

I did one of my favorite talks (What’s new in ADO.NET 2.0) for my favorite user group (VTdotNET) last night. This is the 5th time I have done this talk since March and these guys and gals asked me questions that nobody had asked before (and I didn’t always have the answer) as well as made a lot of interesting observations. I learned a lot. I am excited about digging down a little further into ADO.NET. Because of the discussion, the session went way too long, which is fine for me (I can talk about this stuff all day and night) but really not fair to many of the attendees who get tired and can’t absorb any more after a while. The ability to have this type of interaction without a hard time constraint is what is really awesome about speaking at user groups vs. at conferences. But I think I have to figure out how to balance that a little more without having to cut the talk short.

It’s a broad topic with a lot of ground to cover, but I have actually had to do in one hour once. So I know it can be done!!

I got a very nice email from a first time attendee in which he said “It seemed clear to me that the community and the relationships you’ve built, are such that people are keenly interested in each other’s work and in each other’s learning.  From that aspect alone it’s a pretty remarkable users group.”

This is the kind of feedback that really makes being a user group leader extremely rewarding. And I think that all of the members should feel equally proud.

One big lesson that I have to remember: Have someone else be the user group leader for the night. It’s just too hard for me to run the meeting and focus on the talk as well. I needed someone to take care of me, make sure I had water, got fed, run the raffles, prepare and do the business meeting, etc. Next time! (Which may be next month if our tentative speaker, Dr. Neil Roodyn, is not able to trek all the way across the country in between PDC and the MVP Summit.)