Transactional Update using TableAdapters

Transactional Update using TableAdapters

  • Comments 2

As promised, I’ve put together a sample that demonstrates how to create a transactional update using the new Whidbey TableAdapters.

In this sample I create a Parent, Child and Grandchild relationship.  The tables are named, Parent, Child and Grandchild… J

Using the sample you can see the differences between single table updates and a transactional update.

The single table update will commit each table individually and can get you in a partial state.    If you delete a row in the Parent table, then delete a row in the child and grandchild table, then use the Simple Update, the update will fail.  I did not implement cascading updates in the database.  So, deleting a parent where children still exist is a relational no-no.   


If you update the three tables with the “Smart Update” I use transaction and delete the rows before deleting the parents.  Life is good.


Now I must fully acknowledge that this should be the out-of-the-box behavior.  And for that I apologize.  We did outline some ideas early on, but we ultimately didn’t get them done.


I promise to explain this further as I have time.  I’ve been promising to get this out, so I wanted to at least get the sample up for others to take a look at. 


Works in Everett

I should note that theirs nothing about this example that couldn’t be applied to Visual Studio 2003.  I’m simply showing how to incorporate this work into our new TableAdapters.



Leave a Comment
  • Please add 1 and 3 and type the answer here:
  • Post
  • This seems like a reasonable implementation given the design of the TableAdapter components. I think the manageability of the partial class approach would be improved with a good code snippet, as was suggested on the MSDN Feedback Center.

    I think if I were to implement this pattern in my application I would want to do the following:

    1) Create an Interface that has the AdapterTransaction property.
    2) Implement a code snippet to add the stock logic to implement this interface on every table adapter we create.
    3) Always require developers to explicitly set the AdapterTransaction and Connection properties anytime they do a fill or save operation.
  • PingBack from

Page 1 of 1 (2 items)