Merging Datasets and Updating

After about 4 days of frustration I finally found out how to get this working.

I have a table in a database that I am looking to move to the same table in another database. This seems like an ideal solution for datasets and it is. If you follow the MSDN documentation I found it doesn't work. I have been pulling my hair out and researching datasets for 4 days now trying to figure out why it wouldn't work. When you view the dataset after performing the merge all the data is there and when you perform the update it doesn't error out or throw an exception, however, it didn't work.

What was comforting through this learning experience is that I was no the only one running into this issue. I found hundreds of posts from 2004 to present about this very same issue but not one solution, until today. Some of the seasoned .NET programmers probably already know why, but for those that are still learning I will tell you why.

When you create an adapter, any adapter, and fill your dataset, all rows will be marked as unchanged. This sounds reasonable since you haven't changed anything yet but when you are migrating data it will not work for you. The reason it doesn't work is when you call the update method on your adapter to move it to the new location the method is going to look for rows that are added, deleted, or changed. It is going to completely ignore the rows marked as unchanged. This I understood, what I couldn't figure out was how to mark those rows as changed without manually iterating through each row and making some change.

Enter William Ryan and his great article on "DataSet.Merge and Transferring Data". The way to get this to work is very simple, after you have set up your adapter and before you fill your dataset you need to set the AcceptChangesDuringFill property to false. The reason you set it to false is to get each row in the dataset to be marked as added. Then when you update it all the rows will be added.

I hope this helps some one out and big thanks to William for a great write up.

So many tools so little time.

I am still reading through the test-driven development book and am amazed by the number of tools/utilities that are available for Java. I am able to find some of these for C# but many don't have a counterpart in C#. I am starting to realize how serious of an undertaking practicing TDD is going to be for me. Just going through a mock/stub by hand is not easy, especially when you are just starting to create them. I do think it is a great exercise to improve your understanding of exactly what you are doing but I would not like doing it long term.

So far I am going have to learn, MbUnit, Rhino.Mock, Nester, NCover, and ReSharper, when I buy it. That is a lot to learn but in the end I will be much better off than where I started.

Testdriven.NET and Ad Hoc testing

Since I am fairly new to C# I still make a lot of syntactical mistakes. One of the features I love about Testdriven.NET is the ability to run Ad Hoc tests on a newly created method to make sure it will actually run. This is by no means a replacement for proper Unit Tests but it does at least tell me if I made a mistake with the code that would prevent it from building without going through the entire process of actually building it.

To run an Ad Hoc test add MbUnit as a reference to your current project.
Then create a method. Once the method is "complete" right click anywhere inside the method and select Run Test(s).

I am using the default setup for Visual Studio and Testdriven.NET. This will allow Testdriven.NET to show the output in the "output" pane.

3 months in

I have been teaching myself C# for about the last 3 months now. My background was in C and Assembly and sometime last year I picked up Python. Python was a lot of fun. I didn't need to understand much about OOP to get started and was still able to be functional from day 1.

C# hasn't been so easy. I purchased 2 books on learning C# from Apress, "Beginning C# 2008" and "Beginning Visual C# Express 2005". Knowing what I do now they are great books, however, coming from a C/Assembly background they did not allow me to learn the language. I feel the reason for this is limited exposure to OOP in these books. One of the books had 1 chapter on OOP while the other had 2. After reading both books I was frustrated, lost and thinking about ditching C# all together. That was when I decided to try a different approach.

I went out and purchased "The Object-Oriented Thought Process" by Matt Weisfeld. I have to say that this was the best thing I could have ever done to get a grasp on C# and OOP in general. Most of the code samples were in Java but C# is similar enough that I was able to follow along without getting lost. I learned a lot from this book and plan to reread it several more times to get a better grounding in OOP. It also opened up some new areas I didn't know about, UML for instance. For anyone coming from a procedural background I can't tell you how invaluable this book is.

I then went back and reread my previous 2 purchases and have been happy with the content. The Visual Studio book got me started on creating UIs for my apps, something I have never had a need for. The 2008 book taught me about writing tests for the code that you are writing. This was something new and after trying it out I felt it added alot to my learning ability. I even picked up a new book "Pro C# 2008 and the .NET Platform. This was definitely the next step in C# books for me. It was around this time that I began speaking with a co-worker of mine, Adron, about some of what I was working on. Talk about opening a can of worms.

Adron is one of those guys that if he couldn't do it he would be teaching. I am not talking about the boring lecture types but the one that gives real world concrete examples. He also has a ton of knowledge on process that I never had any exposure to. He starts throwing out terms like "Agile Programming", "Unit Testing", "Refactoring", "Design Patterns". I am just looking at him like he is speaking a foreign language, because he is. That was when he did something I hadn't expected, he gave a 5 minute brain dump of it all. Not everything mind you but enough to wet my appetite and show me why they were important. Now I was hungry again and off to the bookstore to find out what I could on these "new" processes.

So I take a look at all the books they have to offer and realize I am not going to dump $300 on the books I want so I prioritize the list of processes and Test Driven Development rises to the top. I felt that at this point I was going to get the most out of TDD. For some reason I couldn't find anything on TDD in C# but I did find the next best thing, TDD in Java using jUnit. Again Java is close enough to C# that I can follow along and jUnit is close enough to mbUnit as well. I purchased "test-driven development A Practical Guide" by David Astels. So far it has been an exceptional book. It has some minor coverage on refactoring and design patterns already in it. This is another highly recommended book.

The frustrations have been hard but the rewards are starting to pay off.

Some things that I would really like to see change is an improvement in the documentation surrounding mbUnit. I end up using the nUnit documentation to figure out where to start from then fill in the blanks. I suppose it is pretty smart to have another project providing your documentation but until Adron told me to look at the nUnit documentation I didn't even know the project existed. Here is a perfect example. Perform a google search on mbunit and exception assert. I didn't find an mbUnit page until the 44th entry. With nUnit it was the first entry returned.