Bonnie,

I think I understand what you're saying when you say that most datasets are designed around functionality. My application will be storing customer info which is the typical info stored for a customer. Right now I have a Customer class whith GetAllCustomers, GetCustomer, AddCustomer and DeleteCustomer methods. Is this what you're reffering to?

Another question. I'v heard many debates on whether to use sprocs or pass through. I'd like your opinion on this.

Thanks Bonnie!





>>Now that I have invested some time learning how to use DataSets, I'v been thiking that if I created a class for each table, I would have dozens of classes.
>
>Well, I don't think you really want a class for every *table*. Most DataSet classes are designed around functionality and typically contain many tables. Take a CustomerDataSet as an example. You might have a "driving" parent table, Customer. Then you might have several child tables, such as Address, OrderHeader, OrderDetail, etc. These DataTables are all part of the CustomerDataSet. They may or may not correspond to actual database tables. Think of a DataSet has a functional entity rather than just a table.
>
>There's nothing wrong with lots of DataSet classes either. We have ours grouped by functionality ... so we have a project containing Personnel DataSets (it contains several different DataSets classes used for different purposes in our Personnel module). Then we have a project containing Incident DataSets (again, it contains more than one DataSet class). etc.etc.etc.
>
>Just more food for thought. =0)
>
>~~Bonnie