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
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
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
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:
orderTableAdapter.Transaction = customerTableAdapter.Transaction;
catch( Exception e )
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:
|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.|
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.