>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.

There is no magic here.

In file server setups, the only thing that passes over the wire is the (operating system level) equivalent of FOPEN(), FSEEK(), FREAD(), FWRITE(), etc.

This is not "academics". If data requests are formulated properly, the "data engine" (whether it's native VFP or an "ISAM" type of ODBC driver) can read all or part of an index and based on that index, request data that represents an offset and length into a "data file" (vs "reading entire indexes and data" components).

It is a well know fact that many "drivers" can "cache" data. Combined with "large block reads", this can give the impression of extreme increases in performance. Very often a simple SEEK and SCAN will outperform an SQL SELECT because the SEEK/SCAN is more selective about what it retrieves.

I suggest that one think very seriously about making claims that ODBC drivers will increase thruput by up to 250% if one wants to retain a measure of credibility with a client (regardless off what the "books" say).

There are performance monitors readily available that come with Win98 and WinNT/2000 that show what happens at the file level in terms of physical reads and writes; there are no "secrets".