TableAdapter's TableMappings?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I like the new TableAdapter in .net 2005 but is there a designer-based
mechanism that populates a DataSet's multiple DataTables from a stored
procedure that returns multiple result sets. i.e. to configure the equivilant
of a DataAdapter's TableMappings?
 
Hi Richard,

The TableAdapter is a table based DataAdapter, which can only populate 1
DataTable data. If you need to configure the column mapping in the
TableAdapter in the DataSet designer, you can simply change the column
name. The columnn mapping code will be generated automatically. HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
Thanks for your replay but it doesn't quite address my problem.

My dataset's typically have multiple tables in them, Order and Order Item
for instance. Populating them in 2003 was relatively easy but required a bit
of code to setup the connection, the command, the data adapter, the table
mappings, etc. A single call is then made to the DB which returns multiple
rowsets which (via the table mappings) populate the dataset's multiple data
tables. But I'm sure you know all this.

I very much like the new features in 2005 and have already identified how we
could refactor parts of our existing applications with a significant
reduction in code in favour of declarative-based development. But this does
somewhat rely upon being able to populate multiple-table datasets via a
single call to the database. But I can't see how to do this. Any ideas?
 
Hi Richard,

Sorry, but I'm a little confused. Are you using a DataAdapter to fill data
or a TableAdapter to fill data? A TableAdapter cannot return multiple
result sets. Only the first one will be returned.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
I'm sorry to confuse.

My point is, I really like the new TableAdapter and its code-free
declarative method of configuration. But as far as I can see, it is only
useful when the DataSet contains just a single DataTable (or if you are happy
to populate the DataSet via multiple calls to the database - one for each
DataTable).

I can't believe Microsoft would go to the effort to provide the code-free
declarative TableAdapter and not provide a similar code-free declarative
mechanism to populate a DataSet that has multiple DataTables - especially as
the only additional facility would be a collection of TableMappings.

But I can't see how to do this.
 
Hi Richard,

As you know, the TableAdapter will only fill data to one DataTable. To fill
multi-table DataSet at once, you still have to use the DataAdapter. If you
drag and drop a DataAdapter to the designer, you can also use the designer
to set TableMappings. However, TableAdapter cannot achieve that since it's
single table based, which is by design.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
You say "drag and drop a DataAdapter to the designer". How do you do this. My
toolbox only has a TableAdapter (and a Query, a DataTable and a Relation).
 
When you use the Data Source Configuration wizard (DSCW) to create a
strongly typed DataTable (exposed as a "TableAdapter"), you can drag from
the Data Sources window to a Form design surface--not from the Toolbox.

hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Thanks for trying to help but that's not nearly what I'm trying to do.

My original post said something like "the new TableAdapter and the
declarative way to configure it using the designer is excelent, but what
about DataSets with more than one DataTable, i.e. why do these improvements
not include a way to configure the TableMappings that allow a single stored
procedure to return multiple rowsets which populate multiple DataTables"?

Kevin Yu's response said "you can drag and drop a DataAdapter to the
designer then use it to configure the TableMappings". But I can't work out
how to do this!
 
Hi Richard,

The DataAdapter is not available in the DataSet's designer. It's available
in the form designer. You can find it in the Data section. If it doesn't
appear there, you can choose from the Choose Items... popup menu.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
I'm sorry but this seams confussing.

If I understand you correctly, you're saying that if I have a single
DataTable to populate then I can use the new TableAdapter, but if I have
multiple DataTables then I have to use the old DataApapter. This appears to
be two very different solutions to solve two very similar problems. The
former sits nicely on the DataSet designer, is probably in the Buisness Rules
layer and is probably shared by everything that requires the (populated)
DataSet. The latter sits on the form designer and is likely to be accessible
only by the form in question and (as in my case) likely doesn't work in any
case because the UI layer can't see the database!

Surely there must be a better way. Did MS spend time and effort to give us
the declarative-based (and therefore quick, easy, consistent) TableAdapter
but then just forget to give us a way of using them for multiple DataTables.
It's hard to imagine this would happen but, from what you're saying,
nevertheless true!
 
Ah, basically, that's true. The TableAdapter Configuration wizard and the
Data Source Configuration wizard are one-table-only class-builders. They
can't deal with multiple resultset queries. They can deal with a product
created from a JOIN, but not a query that returns two or more rowsets like
the DataAdapter Fill can.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Hi,

I agree with Bill. The TableAdapter only deals with one table. If you need
to put all data into one table, use JOIN in a query. If you need to fill
multiple tables in a DataSet, use DataAdapter.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
Will a multi-table equivalent of the TableAdapter arrive in a subsequent
version? Are other people expressing some surprise at its absence? Is there
any way I can hasten it's arrival?

Or am I barking up the wrong tree? In my VB.2003 projects I have an base
class that (among other things) allows its derived classes to easily populate
their datasets. Should I continue to use this approach in VB.2005? I really
want to use the new tools - partly because they're bright and shiny - but
also because I think (perhaps naively) that they're better than the old ways,
that they're the new best way. And, in this particular case of course, you
can't drop a stored procedure onto a DataSet (to get a DataTable) without
getting a TableAdapter too.

So it looks as if I have four choices:
1. Only use DataSets with a single DataTable.
2. With DataSets that have multiple DataTables, populate DataTables one by
one.
3. With DataSets that have multiple DataTables, populate them from the UI
using a DataAdapter on the Form designer.
4. Delete the TableAdapters from the DataSet designer and populate the
DataSets using code.

It seems to me that option 4 is the only viable alternative. Which makes me
ask: are designers the equivalent to VB.6 data binding, i.e. you might use
them once or twice to mock up a prototype but "real programmers write code"?
 
Hi Richard,

This is by design. The TableAdapter is designed for a single table. If you
need to fill more tables at once, you can only choose the DataAdapter. Or
you have to have a TableAdapter for each DataTable inside the DataSet. And
fill once for each table.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
As read the thread from beginning to end, I found it humorous and
frustrating.

But I have the same question as Dick and have been searching for answers
in the last 3 days but no luck. All points in this discussion are
correct...but you guys were talking about 2 different things.

Here's what I'm looking for. I have an n-tier app. In my Data layer, I
have a DataSet "Component" class that I have populated with 1
TableAdapter. I'll call it UserTableAdapter. You can add a Query into
the TableAdapter and use a stored procedure. As Dick was explaining, the
TableAdapter only returns a DataTable: 1 table = 1 recordset. But what
if you have a stored procedure where you pass the User ID and retrieve 3
recordsets: User Links, User Fav Cars, User Fav Books. Can we actually
run the stored procedure and have access to all 3 recordsets using the
"DataSet Component Class"? If so, how? If not, what's the alternative
to accomplish this?

Dick, this may help shed some light...although I can't replicated how
this guy was able to to fill a Dataset...still trying to figure that
out. http://www.15seconds.com/issue/050721.htm

Scott G Rupp

MartialWeb.com
http://www.MartialWeb.com
Kick it with us!
 
Thanks for the link Scott. Please let me know if you ever get an adequate
solution to our shared question.

For my own part I'm torn between the following views: either (a) Microsoft
simply missed a trick in forgetting to add TableMappings to the new DataSet
designer or (b) most developers return single rowsets from their stored
procedures or (c) most developers don't use the designers at all and
hand-craft all of this type of logic. The trouble is that each of these views
are as unlikely as the others!

I like the designers a lot. No one would suggest that hand-crafting a form
is better than using the form designer and I think the same applies to
datasets. I especially like the fact that you can "extend" the designed
dataset by using either a Partial Class or by using inheritance. I've pretty
much removed a whole layer of "Entity" classes from my current data access
layer and replaced them with classes that have only about 25% of hand-crafted
code. But I've had to redesign and simplify my stored procedures to do this
and I've had to move logic to VB that I think would otherwise be best
performed in T-SQL.
 
Dick,

I am EXACTLY in the same boat as you. I've spent many hours looking for a
".NET 2.0" way to query multiple tables with relations, and when I saw your
post, my heart skipped a few beats, but then came the let-down as I read
Kevin Yu's responses.

I hope that someone can show us a good solution, even if it means waiting
until .NET 2.1.
 
Back
Top