>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?

So, in your application, you have a Customer module which does nothing but deal with Customer information. (I'm assuming that the Customer class you mentioned above is a Biz class?) When I say Customer "module" BTW, I mean everything pertaining to the Customer functionality ... the UI, the DataSets, the Biz classes and the DataAccess classes. This module might use only one CustomerDataSet. That DataSet probably contains more than one DataTable for each "piece" of customer information. This may be all you need to use. Or, to make things simpler, you might also have another DataSet, call it a CustomerListDataSet that only contains one DataTable containing a list of all your Customers.

Of course if your whole application simply revolves around Customers, then your "modules" of functionality might be broken down some other way, or if it's simple enough perhaps you don't need modules.

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

Stored Procs ... definitely.

>Thanks Bonnie!

No problem Kevin ... glad to help (and I hope I *am* helping <g>)

~~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