Hey, I thought you were long gone to happy hour. Last year, at this time, I was working in a really, really crappy job. But the company was located in a tower on Sunset Blvd. It was walking distance to some fun places to hang out.

Anyways, I'm not sure here, but I think that your test brings into play SQL's ability to place the data into the Query Analyzer for display. I just know that in a real world app I wrote, that Fox reports ran faster when the data source was SQL server, than when the source was Fox.

I went back and tried to optimize the query in Fox any way I could, because I must have done something wrong for SQL to be faster than Fox.

I also think it would be easier to optimize a system if it is designed right from the getgo. For example, if you expect traffic to grow substantially and you use SQL Server from the start, you can perform tuning as the traffic starts to grow. Rather than all of a sudden have to upgrade to SQL and have to perform tuning on a web site, for example, that is already getting a hugh amount of hits.

PF

>I agree with you 100%, but your complicating the issue. I'm simply testing the raw processing speed of the query engine without regard to environmental factors, bandwidth, network load etc.
>
>Of course VFP is not as efficient as SQL Server on WAN, it wasn't designed for that purpose. Its strong point is local data processing, and on a good LAN it may even out perform SQL Server and also save your customer a lot of money.
>
>Charlie