>I haven't played around that much with TableAdapters, mainly because what I *have* seen, I didn't like. The TableAdapter Wizard puts crap into my .xsd that certainly doesn't belong there, such as connection strings. My DataSet .xsd's should be DataSet schema and that is all! The wizard *totally* messed with my existing .xsd and I just don't like all the extra stuff it put in there.

I understand your viewpoint on this. If I need to pass around a dataset especially with the schema info then I want it "clean" too. The TableAdapter does put a bunch of crap into the XSD. If your dataset is used for this purpose just use DataTables. You can always create another dataset to hold any TableAdapters if needed.

>
>Also, even though I'm obviously using SqlServer, it generated OleDb objects instead of Sql objects in the TableAdapter ... which is just *wrong*!

What? Check the provider you picked. If I select the SQL provider then SQL objects are used.

>You say that the TableAdapter stuff can be decoupled from the generated DataSet (which it should be, IMHO ... DataAccess stuff has no business being in a DataSet), but I didn't see any automated way to do it ... just cut/paste elsewhere manually and then of course you'd need to do that each time you made changes (I may have missed something though).

I rarely ever instanciate a dataset from within my application. Again I do mostly web development. For winform development I would be more likely to create dataset objects and even pass them around. An example, the TableAdapter class that is generated has a GetData method that allows you to return a typed datatable. No need to create the dataset object. My dataset XSD's are used only to configure data access. It provides a visual designer where I do not have to manually code the datalayer.

>
>Another thing, it seems to generate code only for one DataTable ... even though my StoredProc returns many tables and my .xsd contains many tables. I may have missed something, but this is what it looks like to me. If this is the case, this is totally useless to me.

The TableAdapter provides access to a single defined datatable within the dataset by design. You can return multiple tables from SP to populate the dataset. To do so you have to create a new TableAdapter fill method that calls the underlying DataAdapter fill overload by DataSet instead of by DataTable (the default). If you doing this though then you just as well simply use a DataAdapter directly.

>
>My advice is to skip the TableAdapter Wizard ... it generates a lot of bloated and useless code and you could code it up yourself just as easily and more efficiently. Some of it may be useful to initially see how things work maybe (but still, the fact that OleDb stuff is generated instead of Sql is *NOT* a good sign that it's generating useful code!!!) This is just my opinion, so take it for what it's worth.
>
>~~Bonnie

My view is that TableAdapters have their uses and the TableAdapter Wizard is a tool that deserves a look. It’s definitely not the end all solution to data access and is why I often use O/R mapping to business objects. For me having an integrated tool that provides a visual designer for data access, generates typed DataSets, typed DataTables and the data access layer is quite useful.

I always value your opinion and to me it’s worth a lot. I really appreciate the time and effort given by you (as well as others) and I can never say thank you enough.