Transaction Aware Table-adapters in .NET 2.0

Mike Pagel

Rate me:

4.89/5 (16 votes)

5 Dec 2007CPOL3 min read

85.7K

393

A quick and elegant way to add transaction capabilities to your table-adapters

Download base class - 1.5 KB

Introduction

Much has been said about missing support for atomic transactions in .NET 2.0 when using table adapters that get generated by the dataset designer. This article provides a ready-to-use base-class that by injecting it into a table-adapter's inheritance line equips it with transaction capabilities.

Discussion of Approaches

One way to get around the aforementioned limitations is to configure your server to have DTC (Distributed Transaction Coordination) enabled. In that case, you can use TransactionScope instances guarding actions like modifications through table adapters. However, if you don't want to or cannot change the server's configuration, TransactionScope is not an option.

Others on The Code Project and other sites have explained how to enable transactions for table adapters. The basic idea always is to attach an SqlTransaction to all commands of a table-adapter. If multiple table-adapters are used, share the same transaction across all commands of all adapters. What makes this a little difficult is that a generated table-adapter keeps its SqlDataAdapter property Adapter private, but transaction code requires modifying the property.

There are several approaches to solve this issue. For instance Avoiding DTC with Typed DataSets and SQL Server 2000 suggests adding transaction code in the form of partial classes. As the partial extension lives in the same scope as the original table-adapter, it can also access its private properties. The major disadvantage here is that partial classes have to be created for each generated table adapter.

A much more elegant approach is mentioned in this post (unfortunately in German): use reflection to get your hands at those properties. The article also mentions a small detail I found very interesting: when editing a table-adapter in designer-mode, you are actually able to change its base class! So instead of the default base-class Component you can fill in your own base-class. If you now provide such a base-class that is derived from Component and implements the transaction stuff through reflection, usage becomes simple and elegant. And this is exactly what I did: putting together such a handy base-class called TransactionSupport.

Using the Code

To take advantage of the base class is very simple: First download the class source code and drop it into your project. Then, for all tables in your dataset that require transaction support, change the table adapter's base-class like this:

Select the table-adapter (not the table) in the dataset designer, such that it becomes visible in the properties view.
Change the property BaseClass from System.ComponentModel.Component to the class BizWiz.TransactionSupport I provided like is shown in the screenshot.

And that's it. Do this for each table adapter required. Then you can write code of the following pattern:

// begin transaction and share it among all participating table-adapters:
customerTableAdapter.BeginTransaction();
orderTableAdapter.Transaction = customerTableAdapter.Transaction;

// now start the modifications:
try
{
    // do modifications here, throw exceptions if things go wrong...
    // ...

    // ok, all is well, commit transaction:
    customerTableAdapter.CommitTransaction();
}
catch( Exception e )
{
    // if anything went wrong, roll-back transaction
    customerTableAdapter.RollbackTransaction();
}

You can choose any of the participating table-adapters to perform commit or rollback, but I make it good practice to have one dedicated transaction master, that is doing it all: BeginTransaction(), CommitTransaction()and RollbackTransaction().

History

Date	Comment
2007-SEP-15	Uploaded modified version of base that looks for Connection property of generated table adapters in public as well as non-public scope, as this seems to differ throughout installations.