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