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.
Also, even though I'm obviously using SqlServer, it generated OleDb objects instead of Sql objects in the TableAdapter ... which is just *wrong*! 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).
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.
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
>>Of course this whole CommandBuilder/TableAdapter issue all "goes to h*ll in a handbasket" if you're using Stored Procedures.
>>
>>~~Bonnie
>
>Commandbuilder yes, but as with the DataAdapter the TableAdapter configuration wizard will build the CRUD using either SQL, SP or allow you to select existing SP's. It also gives you the ability to decouple the datatable from the dataset. I know from a winform world that does not have as much impact as it does in the web world.
