VS2005: TableAdapter - need to get the underlying DataAdapter

  • Thread starter Thread starter Jim Rand
  • Start date Start date
J

Jim Rand

In VS 2005, table adapters are used as wrappers to underlying data adapters.
Dragging the tables onto the dataset designer surface automatically creates
table adapters.

Unlike the data adapter, the table adapter throws no events such FillError,
RowUpdated or RowUpdating.

In VS 2003, you needed to trap inserted rows for a GetChanges() dataset
using an event handler like:

private void sqlDACustomer_RowUpdated(object sender,
System.Data.SqlClient.SqlRowUpdatedEventArgs e)

{

if (e.StatementType == StatementType.Insert) e.Status =
UpdateStatus.SkipCurrentRow;

}

What are my options?

1) Not drag tables onto the designer to avoid getting table adapters? That's
a pain because you have to write a small program to get the underlying table
structure from the database into a dataset and then write an xsd to be
imported into VS 2005.

2) Copy and paste from TableAdapter.InitAdapter to my own class to create a
data adapter.

3) Burrow into the TableAdapter through reflection to bypass the private
modifier.
private System.Data.SqlClient.SqlDataAdapter Adapter {


Your thoughts

Thanks
 
Hello Jim,

You could create the Typed DataSet and ignore the TableAdapters (which isn't
a bad idea IMHO). Then create a component (to get a designer surface) and
design the DataAdapters like ou could in 1.1.


Thanks,
Shawn Wildermuth
Speaker, Author and C# MVP
http://adoguy.com
 
Double click on the designer surface for your dataset's XSD. This will
create a partial class. You can then insert the following code to expose
your DataAdapter.

Namespace myDataSetTableAdapters

Partial Class myDataTableTableAdapter

Public ReadOnly Property sqlAdapter() As SqlDataAdapter
Get
Return Me.Adapter
End Get
End Property
End Class
End Namespace
 
Wow! That is most interesting!

I was going to use the table adapter as a SELECT only designer aid and use a
component loaded with fully functional data adapters in run mode.

I did discover that the generated code does not prepare the SELECT command
until the first Fill.

As a result a call like:
categoryTableAdapter.daCategory.Fill(dsEastwind.Category) fails with

System.InvalidOperationException: The SelectCommand property has not
been initialized before calling 'Fill'.

while a call like: categoryTableAdapter.Fill(dsEastwind.Category) works.

Now, thanks to you, I can have my cake and eat it to.

Thank you, thank you, thank you.
 
Thanks,

I was going to go this route until JT came up with a way to get a handle on
the internal data adapter.
 
Back
Top