Chris,

One of the problems with pulling down all the data at once is bandwidth. You have to think of such things when doing client/server apps. That is all I meant by avoiding multiple parent rows. But, I'm guessing that you know all that already. The scenario you mention is a little different than what I was addressing. In your scenario, yes I agree with only pulling down the child detail rows as you need them.

But, back to the DataSet issue and why I suggest one DataSet with many tables. We are using typed DataSets in our app that we are designing (the resulting data object's .dll will be a little bigger, but typed DataSets are infinitely more useable, IMHO). We would like to minimize the number of different DataSet objects that we design. It makes sense to combine all the functionality of a business object into one DataSet, and then you can re-use the same DataSet "structure" for multiple uses.

So, in your scenario, I might have an Order DataSet that contains an Orders table and an OrderDetail table. In your application, you can use the same DataSet "structure" multiple times, filling them with data from different Stored Procedure calls.

OrderDataSet dsOrders = new OrderDataSet();
OrderDataSet dsDetails = new OrderDataSet();

dsOrders = this.FillOrdersFromCustomers("MyCustomer");
.
.
.
// later in the code, after choosing a particular order
dsDetails = this.FillOrderDetails("OrderNumber");

Now, this might seem a bit silly to design an Order DataSet like this, and only use it to fill the individual tables. But, when you consider that you can use this same DataSet for other uses when you actually might need both tables filled, it makes sense (and in fact, the SP that is called from the FillOrderDetails() method would probably fill the Order table as well as the Details table).

Anyway, do you see the point that I'm trying to make? (or am I babbling endlessly as I am wont to do? <g>)


~~Bonnie



>>Chris,
>>
>>>>I would say it depends on what you are going to do with the data and how much of it you have. If you have a parent detail relationship where there are a lot of child records to each parent I would go with separate datasets and pull new detail with each skip through the parent.<
>>
>>In this scenario, I would *still* go with one dataset, three tables. You would not (or at any rate, should not) be pulling in multiple parent rows. One row in the parent table, then only related rows in the child tables.
>>
>>~~Bonnie
>>
>
>So then what would you do if you wanted to show all of a customer’s orders and let them scroll through the list to see the details?
>How would your application benefit by avoiding multiple parent rows?