Undersanding DataSets - Under the hood
Posted on 2007-07-29
This is regarding VB 2005 as I'm trying to get a clearer understanding of DataSets.
The way I understand it is that when you add a DataSource to your application it creates TableAdapters. These initially have nothing to do with the DataSet since one hasn't been created at the time of adding a DataSource which is why they have their own Namespace.
Now we create a DataSet using the Designer (although we don't have to use the designer as I understand it, I am right now). We can add all our tables and then any relationships we want defined at design time. So far so good.
Now, when we add a table to a form, things start to get fuzzy. What I see is a DataSet created for each form I add data to. It seems wasteful to have a full set a of Data, particularly if you have a DataSet with a lot of tables, say 25 or more created for each form.
Would this mean that each form has a full copy of all the data from the database of all the tables in the DataSet? That would be very wasteful. Or, does the DataSet copied onto the form serve as a mechanism for keep all data used by the form synced up but only data that form uses out of that DataSet is actually pulled from the Database along with any required related data as defined by the relationships in the DataSet?
The second scenario would make more sense from an efficiency point of view unless the Application was relying on some sort of caching of data that all DataSets in the application pull from, which I wouldn't discount with data pooling and so on.
Right now, to keep all forms synced up with each other I replace the DataSet that is on the form with a global DataSet (such as: Me.TRUWESTDataSet = DS) that I setup at the start of my App. This works well but understanding more of the underlying efficiencies on how things work, or lack thereof would certainly help with me knowing whether my architectures where reasonable for the application/usage for which they are designed.