>>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.
>
>Disagreed, because VFP-performance will be
>a) specific to each workstation hardware
>b) depends on interface arrangements. Assuming that you compare with SQL-server, i.e. just one/few records will be 'retrieved' by interface at a time, then SEEK() will be probably even faster.

But SEEK() in and of itself is totally not client/server. So if the app by definition cannot do any seeks, but instead must do Select-SQL statements, this is where VFP is hindered immeasurably by having to read large amounts of index data over the wire. Remember item number 1 in the "givens" area. No SEEK() calls allowed. The same code has to execute whether you are running with VFP or with SQL Server, meaning that views have to be used almost all of the time.

>>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.
>
>Agreed. However VFP Select-SQL may also give good results, and it still not client-server.
>

It doesn't. Not when you look at the example I showed. VFP sends 30MB over the wire and takes 20-30 seconds to perform the query while SQL Server sends only the result set over the wire and takes less than 5 seconds. The key here is that the data is not local to VFP, but it is local to SQL Server. If you bring the data local to VFP, the times are very comparable. But expecting the data to be local is not realistic when you're talking about a multi-user client/server application.