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

Actually, I didn't make the claim of performance increaes of 250 %, the book did. What I saw was a significant performance increase. It was enough to warrant using that solution because we did not have time to do a major rewrite and the company was not going to throw any more money into the network. The fact is the results were astounding, and I have yet to find a definative explanation for it, despite your excellent analysis.