TableAdapter properties

W

wsyeager

Well-known member
Joined
Apr 10, 2003
Messages
140
Location
Weston, FL
Is there a way to expose the SqlDataAdapter within a TableAdapter as a Public property even after re-generating the TableAdapter?

I cant use TableAdapters, because they dont expose the SqlDataAdapter as a Public property since I need to pass down the DataAdapter to a separate DB I/O method. Not a generated DB I/O method within the TableAdapter. Im forced to use the Component Designer and create a SqlDataAdapter like I have been doing in VS.Net 2003.

The following code is generated when creating a TableAdapter:

Code: 
<System.Diagnostics.DebuggerNonUserCodeAttribute()> _
        Private ReadOnly Property Adapter() As System.Data.SqlClient.SqlDataAdapter
            Get
                If (Me._adapter Is Nothing) Then
                    Me.InitAdapter()
                End If
                Return Me._adapter
            End Get
        End Property
        
        <System.Diagnostics.DebuggerNonUserCodeAttribute()>  _
        Public Property Connection() As System.Data.SqlClient.SqlConnection
            Get
                If (Me._connection Is Nothing) Then
                    Me.InitConnection
                End If
                Return Me._connection
            End Get
            Set
                Me._connection = value
                If (Not (Me.Adapter.InsertCommand) Is Nothing) Then
                    Me.Adapter.InsertCommand.Connection = value
                End If
                If (Not (Me.Adapter.DeleteCommand) Is Nothing) Then
                    Me.Adapter.DeleteCommand.Connection = value
                End If
                If (Not (Me.Adapter.UpdateCommand) Is Nothing) Then
                    Me.Adapter.UpdateCommand.Connection = value
                End If
                Dim i As Integer = 0
                Do While (i < Me.CommandCollection.Length)
                    If (Not (Me.CommandCollection(i)) Is Nothing) Then
                        CType(Me.CommandCollection(i),System.Data.SqlClient.SqlCommand).Connection = value
                    End If
                    i = (i + 1)
                Loop
            End Set
        End Property

Notice that you can set the Connection property as a Public property in the DataSet Designer, but there is no such option for the DataAdapter.

Just for kicks, I modified the code to make the DataAdapter a Public property (changed the Boldfaced Private to Public above), and was able to access it in code as follows:

Code: 
Dim ta As New DataSet2TableAdapters.CustomersTableAdapter
        Dim dst As New DataSet2

        DataAccess.Data.SQLServerDataAccess.GetSQLData(ta.Connection, [B]ta.Adapter[/B], dst)

The Adapter contains the associated Command objects and passes it down to the DB I/O layer performing the appropriate FILL or UPDATE command. In this case, its obviously the FILL command.

So, Microsoft should have made an option not to tie the TableAdapter to DB I/O code from within the generated code itself.
They also should include an option to make the generated DataAdapter a Public object (as seen above).
I hope this gets fixed in a service pack release. Barring this, does anybody know how I can consistently make the DataAdapter appear as a Public object?
 
Last edited by a moderator:
The whole point of a TableAdapter seems to be creating a type safe DataAdapter based on the underlying DB structure / procedures, exposing the DataAdapter as a public property would allow external code to alter things in such a way as to break the TableAdapter (changing the command string, shoving invalid parameters into the commands.parameters collection etc.) and would generally defaeat the point of using a TableAdapter.

If you already have your own data access layer why would you use wizards to generate another one, especially one that doesnt fit with your way of working?

If you need to use DataAdapters directly why not create your own class that exposes them centrally, that would prevent you from needing to use the designers in a 2003 style (they were never that good an idea as they resulted in massive code duplication anyway).
 
Back
Top