Perry,

I know Dino's supposed to be some sort of guru, but I disagree with him on a few things. Typed DataSets being one of them. (yeah, yeah ... so I don't have the name recognition that he does, but hey, I'm not exactly a newcomer to this stuff). I have no clue why anyone would rather re-invent the wheel creating custom objects when a Typed DataSet can pretty much do anything you'd want it to do. Now, that said, I *do* sub-class my Typed DataSets and add some additional functionality to them ... but by using a DataSet as the parent class, my DataSet classes have a lot of built-in functionality that I don't have to recreate in a custom object.

He is right about retrieving data in vast quantities though ... gotta agree with him there.

~~Bonnie


>I was just reading a Dino Espinosa article in MSDN mag last nite. It was about data retrieval. His only comment about thousands of rows is that if you are doing it several times in your app, it's probably time to look at the design.
>
>He makes the argument for using custom business objects, rather then data sets (fine for small data sets) or typed data sets (doesn't like). Of course custom objects take time to write, but if it's an enterprise type system, you will gain the time spent up front with time savings on maintainability later.
>
>>Sid,
>>
>>Not to get into a major .NET discussion here, but I gotta wonder how you're getting that data for a 1 million row DataSet? If it's coming in over the wire, I don't see how 2.0 makes any difference, since the bottleneck would certainly not be from ADO.NET, but simply the speed of retrieving all that data. (SQL Server or what?)
>>
>>Just curious ...
>>
>>~~Bonnie
>>
>>>Regarding your problem with .Net: if it is ADO.Net then I think it's worth it to give VS2005 a shot. VS 2005 use ADO.Net 2.0 which is much much faster. With ADO.Net 1.1, creating a dataset with 1 million rows takes anywhere from 4 to 8 minutes. With ADO.Net 2.0, it takes well under a minute.