Connection and Transaction properties exposed as Friend on TableAdapters

Connection and Transaction properties exposed as Friend on TableAdapters

Rate This
  • Comments 11

Connection Modifier Changes

In the Beta 1 build of VS 2005 we expose the Connection as Friend. 

Friend ReadOnly Property Connection() As System.Data.SqlClient.SqlConnection

Based on user feedback and usability studies we've found that this has caused confusion.  We've found that when users are creating DataSets within their exe projects they are attempting to interact with the TableAdapter within the form as if it were a configured 2003 DataAdapter.  By exposing the CommandCollection, Connection and Transaction properties, users believe this is how they would modify it.  The model we’ve optimized for the TableAdapters are to define the base implementation within the DataSet Designer and then call the specific methods.  While we don’t wish to disable the scenario where users need to make changes to the underlying connection object of the TableAdapter, we feel this is the less common scenario.  In most cases the only value needed to be changed on the connection object is the ConnectionString which is assumed to be managed through the Settings class.  Because of this, we will be changing the TableAdapter.Connection to Protected and thus will no longer be exposed when the TableAdapter is instanced on a Form. 

When developers need more advanced support for changing the connection object, the Transaction or CommandCollection they can use the Partial Class and add their own DataConnection property and implement as they wish.  If the DataConnection was exposed as Settable, then the user would need to iterate through the CommandCollection and set each Connection of each command. 



Transaction Property removed:

The code we currently generate for the Transaction property on the TableAdapters doesn’t work in all scenarios.  While we could do some more work to make this a bit better, the real value is to enable transactions between two specific methods, and even abstract the amount of code the user needs to write.  For instance, the developer should just be able to call an Update method which in turn updates two ore more tables within a transaction.  All set through the designer.  Because we have several bugs on the Transaction property as currently defined, and we’re concerned about the expectation of this property, we’ll be removing it.  Developers can still add their own Transaction property to the their TableAdapters through partial classes.  I hope to have a snippet completed to make this easier as well.


These changes should appear in the first Technology Preview post Beta 1.


Steve Lasker

Leave a Comment
  • Please add 2 and 6 and type the answer here:
  • Post
  • Fortunately, I Googled 'tableadapter' 'transaction' and found this post. Unfortunately, it was after spending a few hours trying to make the TableAdapter.Transaction property work as I had expected.

    It appears as if writing Partial Class code for sequenced (deleted, added, modified) updates for two or three related tables in a transaction will be a major PITA. All update operations appear to open and close their connection.

    I'd sure appreciate some hints or VB sample code that handles the chore. My demo apps use Northwind in SQL Server 2000 and added to 2005.


  • This seems like a major step backwards. Having to do this for every table adapter in our system will be onerous (we have more than 200 tables). The current design seems oriented towards casual, amateur developers rather than enterprise-class developers.

    I strongly urge MS to reconsider this approach. If the properties are causing you problems, why not just code-gen extra methods that take the existing params plus a connection object and transaction object (tran object only on update methods)?

  • I have to agree with Jeff. Our standard model for data access layers uses Enterprise Services, and the connection is managed from a base class that sits in a different assembly. The rest of the Table Adapter model will fit nicely into the way we do things, but the Connection not being accessible outside the assembly was already a pain, now you are making it less accessible. Having to add code to support this for every table adapter is going to cause a lot of pain. A data access layer does not know enough about the context in which it is going to be used to assume full responsibility for connection management, so the Connection of all things should be a settable property on the Table Adapter from outside the assembly.
  • Ok, so how about this:
    We expose a ConnectionModifier property on the DataSet designer that defaults to Protected, but developers can easily change to Friend or Public.
    The issue is we've heard clearly that we should expose sensitive data, such as the Connection info, or the Command Collections outside the assembly. Our believe is connection strings would be well managed through the Settings class. If you change the Settings.YourConnectionString, the TableAdapters would utilize this value. However, I do recognize that developers do have well designed patterns that delegate the creation of a Connection to another library. the property.
    Creating a partial class for each TableAdapter would be PITA, and oh, by the way, we did likely steal the name you'd use Connection, so is it reasonable to default to Protected and you can simply toggle this in the Designer. Please don't ask for a Tools-Options to change the default :) This would be a simple thing to add at this point, and we're still hearing "ship it already".

    BTW, still haven't had a chance to finish the Transaction sample, but I do have some of it done...
  • PingBack from

  • PingBack from

  • PingBack from

Page 1 of 1 (11 items)