Missing table adapter in dataset components list

[gwboolean]

I just added a new table to an existing dataset for a project (about 15 minutes ago). I then went to the dataset.xsd to make sure that it was there and everything was in order with the new table. So my question is, when is this going to show up in the dataset components list in the toolbox window? How does one manually add that instead of waiting for the toolbox to takes its own sweet time in finally taking care of that?

[jmcilhinney]

If you added a new DataTable to your DataSet then nothing is going to be added to the Toolbox. If you added a new table adapter to your DataSet then, after building your project, that table adapter should appear automatically. If you did the latter and you don't see anything added to the Toolbox then something has gone wrong and all I can suggest is to delete the table adapter, save everything, restart VS and try rebuilding your project. Note that that is rebuild, not just build.

[gwboolean]

Apparently I was not clear enough. I added a table to the database, then went to the datasource window and configured the existing dataset to add the table to the dataset. And yes the table adapter did, eventually, show up in the dataset components in the toolbox window. It is clear to me that something is not quickly updated. It is my guess that, after waiting for nearly 20 minutes, that I needed to rebuild the project, which is what I did. After doing this the table adapter showed up. So are you telling me that there is no way to manually do this? If so, that is a rather clumsy and less than efficient (or perhaps weak) feature within Visual Basic.

[jmcilhinney]

The Toolbox looks in compiled assemblies for components to display. If you select Build > Clean from the main VS menu, which deletes all compiled output for your solution/project, then open the Toolbox again then you'll see that all your table adapters and your DataSet have disappeared. It's not clumsy or weak. The code for the Toolbox window would be significantly more complex if it wasn't that way because it wouldn't be able to leverage existing functionality to load components from the current solution but rather would have to constantly look through uncompiled code to see whether there were any components and also whether they actually would compile to determine whether to add them or not.

I have not once had an issue with this functionality and don't know of anyone who has. Building your project isn't exactly an onerous task and if you find that you're adding a new table to a database in the middle of another task that prevents you from compiling then you probably aren't planning your work very well. If you're doing something that requires a new table then adding the new table should be the first part undertaken, given that the database is the lowest layer. You can then build the project and access the table adapter from the Toolbox as you add the functionality to make use of that table.

That said, you'll find that most experienced developers will tell you not to access table adapters from the Toolbox anyway. If you are then that means that you are tightly coupling your presentation code and your data access code. It's exactly because of what you're doing that typed DataSets have a bad name: because many people are under the impression that that is the only way they can be used and it's bad from an architectural perspective. We all tend to put our data access code in our forms to begin with, whether we use typed DataSets or not, and Microsoft added the functionality you're using to make that easier. If you want to follow best practice though, you should strive to decouple your data access code from your presentation code. In theory, you should be able to use the same data access code with a WinForms app, a Console app, a web application, etc, without change. You can absolutely do that with a typed DataSet but you can only use the Toolbox - and the Data Sources window for that matter - to add data access components directly to forms and thus tightly couple the two.