>>With odbc, all you are actually sending over the network is the sql statment, and all you get back is the result... the index and database files, which are stored on the server, never get actually moved to the client workstation.
>
>The "ODBC Driver" executes on the *Client* in a "file server" setup. There is no "sending" of sql over the network (as in a client/server setup with an "SQL Server" or DCOM type of backend).
>
>Any "increase" in thruput is probably due to "recoding" of the relevant statements going from "native VFP" to "ODBC/Remote Views"; implying that the orignal VFP statements were not fully "optimized" to begin with.
>
>All a "file server" does is accept request for "file offsets" and "byte lengths" to read/write; it has no clue what to with with an "SQL statement", whether it came from an ODBC driver or VFP's "native data engine" (or MS Access for that matter).

Although my own benchmarks showed amazing performance increases, I could never explain why. And according to page 126 of "Cleint/Server Appplications with Visual Foxpro and Sql Server", performance increases of 250 percent or better were achieved in situations where file servers were on low-bandwidth local networks. The authors could only theorize why this was happening, and Microsoft will never divulge secrets about the data engine, but I have seen the results and so have others. Academics aside, the results speak for themselves.

I wish I could explain it, but I can't.