>Your not alone. I discovered the same thing. Many of the forum guru's told me that I should not worry but I did anyway. What I did find that might be of help is - if the query is run from a workstation using foxpro databases that most of the index file is transfered (this was very large in my case). That was using a select statement. If I used a seek statement I found that the program run 1000% faster. I was not able to test the amount of data that was transfered because the seek was to fast to see on the perfmon graph. Using MS-SQL from a work station was not as fast as the seek but was much easier on network bandwidth. The query was not nearly as fast as the foxpro seek - but better that the foxpro select by a little. What I understand at this time is nothing. On one hand the MS-SQL is going to be the future. Just read any trade mag. But on the other hand foxpro was faster. Now what is a guy to do! BTW my server was a dual 400 PII 1G of ram, LVD scsi drives, 100BaseTX
>full duplex, 3 intel NIC'S, 3com switches.
>
>John

PMFJI, But I think you are overlooking the overhead incurred by SQL Server during the connection. Before it runs the query, it must establish a connection, then must verify your access to the required table objects. This overhead is enough to allow VFP to run a single query a bit faster, even though you are running the query from the server machine.

If you were to graph performance, SQL Server would start out with a higher response time for one user, but would not grow as step as VFP as more concurrent users are added. The real challenge is determining at which point VFP or SQL makes sense in your environment. Not to mention remote users or internet users of you product.

If you need ultimate performance from this query, why not rewrite it as a stored procedure. That way, the query will be saved parsed and the access plan created.