Given the following:

1) Full client/server application, never opens base tables directly, only uses views, etc.

2) Application can utilize either the built-in VFP engine or SQL Server.

Do you agree or disagree with the following statements? Why?

1) Using SQL Server as the data engine will perform 3 to 5 times faster than VFP and there's nothing you can do about it.

2) If the application were modified to take advantage of "older" style code, such as SEEK followed by SCAN WHILE..ENDSCAN, it would no longer be a client server app, but it could perform comparably to the client server app running with SQL Server.

I ask these things because this exact scenario seems to be happening. We converted a very large FP 2.6 app over to VFP, and along the way we also converted it over to a design that is fully client/server compatible, knowing that we would eventually want to be able to use SQL Server on the back end. The fact that we're fully client/server seems to hinder VFP considerably, as huge amounts of index data has to go across the wire to do SQL SELECT statements in VFP. For example, our testing revealed that doing a fully optimized query such as this:

SELECT * ;
FROM aaprocqt ;
WHERE estno = lcEstNo ;
INTO CURSOR vaprocqt

on a 200MB table with a CDX that is approximately 65MB, and has an index on just estno as well as DELETED() results in 20-30MB of data going over the wire. Obviously if we did the following:

SELECT aaprocqt
AFIELDS(laStru)
CREATE CURSOR vaprocqt FROM ARRAY laStru
SEEK lcEstNo
SCAN WHILE estno = lcEstNo
SCATTER MEMVAR
INSERT INTO vaprocqt FROM MEMVAR
ENDSCAN

there wouldn't be anywhere near the same amount of data going over the wire, but this second example is completely NOT client/server.