>Well, the fact that I never needed to handle a million records does not mean it might not be an issue for others, I have a program that generates 2D graph that needs near 75K records, and it is simple, so I can certainly see that more complex or 3D graphs requiring a million records. But, even if you can stream the data a record at a time, why would you do it if you can pull the data faster at once to process it locally to generate your graph/object or whatever visual representation you need?

Streaming does not imply pulling data slowly or reconnecting. In .NET using a DataReader streams the data while connected and you access the data while it's coming down one record at a time. Add to that the ability to do this on a background thread while other UI or process work takes place and you have the ability to very efficiently pull data down to the client. Streaming data in this fashion is very low level and likely going to be faster than streaming data into cursor for example - certainly than synchronously waiting for a query to complete.

Look, my point is not that .NET is necessarily better at doing this - it's just different. Like I said a bunch of times before here - if you think of doing things the VFP way in .NET you'll think it sucks. But with the right approach and some different concept you can - most of the time - provide the same functionality with the same or better performance. People are writing high end applications in .NET every day and people write high end applications in VFP. It can be done in either and if you know how to use the tools either allows you to do it with reasonable ease.