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!

"Kevin Yu [MSFT]" wrote:

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.
__________________________________

"Dick" <Richard.Giles (AT) nospam (DOT) nospam> wrote

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"?

"Kevin Yu [MSFT]" wrote:

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!

*** Sent via Developersdex http://www.developersdex.com ***

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.

Ouch! This thread was painful for me too. I think this might help.

http://msdn2.microsoft.com/en-us/lib...33(VS.80).aspx




*** Sent via Developersdex http://www.developersdex.com ***

Here is the answer & a work-around, straight from the VB Team:

http://blogs.msdn.com/vbteam/archive...er-multiple-re
sult-sets.aspx

You can also create a new Component, add a SqlDataAdapter to, then do
the table mapping. This need more code to hook up the dataset and the
new component, but it's visual if that's what you're looking for.


*** Sent via Developersdex http://www.developersdex.com ***