Thanks

Yes with very big files SQL server is always going to faster.

However I keep seeing apps that have been ported over to SQL Server and they appear to be running much slower than the VFP apps they replace.

I suspect that is because these apps only have smallish tables to start with and that putting them in SQL Server represented an overkill.

However since the data has now been centralised by putting them in SQL I guess the overhead is justified.

The products are too different to compare in this way really:)



>The chap in your office may be right. On a local machine, VFP will hold up against SQL in moderately sized tables, however on a network, with larger tables, VFP is playing catchup. On a network, all the data specified in the query by VFP from VFP tables is transmitted over the network whereas SQL executes the query at the server and only returns the result. Also, SQL usually operates with more server resources so it does things that VFP has to do double duty on. There are ways to keep VFP competitive to SQL in terms of speeds but usually it is a catch up game at best. Let's face it, SQL loads an additional cost of between $100 to $150 per workstation to support, whereas VFP has no such cost. It stands to reason that it has to have some performance benefit to the user.
>
>HTH,
>
>Bill
>
>
>>I know that is not comparing like with like but....
>>
>>Does anyone have a set of benchmarks that compare a select in VFP with a select in SQL Server.
>>
>>I would expect VFP to be dramatically faster if they are both running on the same spec machine, but how much.
>>
>>I am only doing this because a chap in my office has the idea that SQL Server is faster:)