>I think you are not seprrating the 'requierment' of doing something with the 'implementation' of doing it. In VFP you do it the VFP way, in .Net you don't, you do it the .Net way. Does that make .Net bad at doing it? I don't think so.
>
>So, if you can't show me a reason to bring those 100 or 10,000 records out of the database and across the wire to 'process' them, then I would recommend you do it in the SQL Server.

I basically agree with you that it's best to pull data in small chunks and let the backend to the chunking of the data for you.

BUt it's usually it's reports that require this much data. The problem is that ADO.Net DataSets are 100% memory based, which means if you pull large amounts of data you have all that stuff in memory.

Performance of large datasets is abysmal even when pulling as llittle as 1000 records and then doign something with it. There are ways around this such as using DataReaders, but depending on what you use for reporting that may not be appropriate.

This is a problem I've run with several clients - ultimately there was a way around this by breaking up how data is pulled, but then this shouldn't be necessary either. In an Enterprise level tool there should be a way to work with large amounts of data on the client end efficiently...

There are always workaround for eveyrthing. But then that is the starting point for hte .Net argument in the first place right: Getting rid of the 'workarounds' we have to do in VFP to accomplish so many things - with the exception of data access.


I know you're a big SQL guy and I have over the last couple of years also have gotten much more familiar and even fond of SQL Server. But I tell you that I can't use SQL Server for many things that I build which is many tools and smaller shrink wrap apps. SQL is fine operationally, but from an administrative point of view it's a pain in the butt. You can't sell an app into an end user market with SQL Server, definitely not into the consumer market. Although you you can automate everything it requires SQL Admin rights to do so.

VFP and OleDb are also not an option IMHO, because through OleDb you can't efficently access the data nor get full control over it (for exclusive tasks).

This is one very common scenario that .Net does not address. THere's no decent medium level data access mecahnism built-in. Microsoft has systematically wiped out the mid-level database market and now there's nothing viable left but SQL Server/MSDE in .Net. Access/Jet, yeah right...

There are third party products that fill this void - Appollo, Db Vista and Codebase for example, but again this seems like something that should be available in the box.

Not that I'm holding my breath. MS is not going to give up the SQL Server cow by providing data options.

Alot of folks have to remember that not all apps go into big corporate environments. A lot of apps go to consumers and small businesses that have 2-5 users.