Weste said:
I have 2 questions regarding designing typed data sets. Say an application
has 20 tables. Is it better to create a single data set with all 20
tables
or should you create several data sets each including only the applicable
tables for a particular form?
Six of one, half dozen of the other. If you do not fill the other tables,
they will be very small (schema only). This is for YOUR application, of
course. If you are communicating to a web service, for example, you will
have to match its definition, which may dictate multiple datasets.
The other side of the equation is how you structure your application. I have
seen apps, for example, where each page had its own dataset. Whil this leads
to far more datasets and some repeat of code, it does make an easy
maintenance path for newbies, as long as database schema does not change
often.
Pros:
* work on page, work on dataset
Cons
* May have multiple datasets to change if underlying schema changes
There are O/R layers (Persistant DataSets comes to mind) where the entire
schema is in one dataset and you only fill what you need for the work you
are currently doing.
Since data sets are stored in memory, should you clear each table's data
when you are done with them? Take the Northwind database for an example.
Say there is a form using the customers table from a data set. After the
user closes the customer form, should the data table be cleared from the
customers data table?
This depends on the type of work you are doing. I assume you are creating
smart clients rather than web apps. If you are going to hold the data from
form to form and work with different data, you should either a) clear out
the data or b) refresh the entire dataset with the data you are now going to
work on (i.e. create a new instance of the data, focusing on the task at
hand).
If I were doing the example you have above, I would submit back changes and
completely kill the dataset when the form was closed. If the user then works
with other data on another form, I would grab data pertinent to that task.
If the changes had to be reflected on an open main form when the user
changed data on the customer form, I would refresh the data for the main
form. The CAB (Composite Application Block) is a nice block for creating
multi-form apps with forms that interact with each other.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
*************************************************
Think outside of the box!
*************************************************
