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.