>Besides being the "NEXT" thing can .NET outrun the Fox?

Depends on what you're looking for <g>...

Here's my take. VFP is fast especially for local data access and performance of a Fox app will almost always be better than what you see for a .Net (Windows Forms app) unless we're talking about a high end super scalable system in which case if you compare apples to apples performance will depend more likely on the backends performance.

One thing that really bothers me about .Net is that there is no local data engine. Sure I can use MSDE/SQL Server locally but this is a nightmare especially for shrink wrap applications that need simple data access (maybe a few tables). For example, something like Help Builder or an offline message reader etc. - the problem here is configuration is a nightmare you can't just fire away and create everything unless you have the proper installation of MSDE/SQL and it's configured to allow access etc. etc.

Performance too in that kind of scenario generally is better with Fox because the data is small and consists of mostly free form queries and text
searches (which SQL is really bad at).

The other thing I have noticed is that hte .Net WinForm datacontrols are slow or alternately so simplistic or badly designed that they're unusable for all but the simplest tasks (the WinForm DataGrid comes to mind). Third party controls address some of those issues. The key here too is to try and work with smaller chunks of data in the UI and when you do the UI is flexible and responsive. However the big bonus I find with WinForms is that the platform is supported by a host of killer third party and free controls so you can build very pro looking apps - something that has always been difficult with Fox since a lot of UI based controls don't work with it...

.Net is notably bad with lots of data retrieved to theclient. If your WinForms app requires lots of data for local processing (ie. you pull a huge DataTable from the server) .Net performance downright sucks. This is because all this stuff goes into memory and if the data is large the performance sucks the whole system down. Although one should avoid pulling this much data down (filter it before it comes) sometimes there's no avoiding it (for report generation for example).

Obviously the main data processing depends on what backend you use and in my (limited) experience with larger data SQL Server and ADO.Net are very fast and flexible. The performance here is determined not by .Net though but mostly by SQL server.

Now where .Net really shines though is in the Web stuff. Pure performance there is not any better than what you can do with FOx, but the scalability that goes with it is considerably better. Even not counting features like Output and data Caching in .Net (which if applicable can improve Web performance 10 fold or more easily) I have tested several functionally equivalent Fox (Web COnnection and one ASP/COM) and ASP.Net apps and even without takeing advantage of caching the ASP.Net app easily runs twice the load of the Fox counter parts. With caching added it's no contest...

This may or may not matter though. The WWWC Fox app was running around 60 requests a second, the ASP/COM app around 50, and the ASP.Net app close to 120... 60 requests a second on a notebook no less is more load than most people will ever need for their apps. So pure performance of Web applications is starting to become an issue that doesn't matter for all but the biggest applications that can actually fill the performance of the hardware.

The big plus for ASP.Net in this scenario is that it's so much easier to deploy - you copy the files and your done. Well, not quite but pretty damn close... THe object model is also extremely flexible and lets you do things that are otherwise very difficult to. Nothing that you can't do with a 'more straight environment' but it's just easier to work through the model. ASP.Net truly is a marvel of a design...

So no straight answers Glen <g>... as always it really depends on the application. But I would say from the way that your question is phrased that you mean data apps, and my take is that you can build very fast data apps indeed.

+++ Rick ---