>>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.
>
>Maybe this will put it into perspective:
>
>Take the VFP EXE/Run-Time and strip out the IDE and all the GUI related commands/statements; what you wind up with is the "VFP ODBC Driver" (ie. a portable version of the VFP "data engine") with an ODBC API bolted on.
>
>The only difference between the VFP ODBC driver and the native VFP data engine is that the ODBC "might" be doing some extra bachground fetching.
>
>If the ODBC driver outperformed the "native" data engine it was a "fluke" and a review of the original code would have solved the problem (or simply rerunning the same set of samples a couple of times to allow for caching).

I would tend to agree with you that the added overhead of an ODBC process/layer running on the same machine should, on balance, slow things down rather than speed them up.

The ODBC driver runs as a separate process with its own memory space. In James' case the "native" app may be RAM-constrained via SYS(3050). In the ODBC case, the original app may be able to call on a non-constrained ODBC driver, effectively throwing more RAM at the entire problem.

If the ODBC driver is not constrained it could indeed be pre-fetching more server data to local cache - in this case acting as a sort of local database server.

Without knowing VFP low-level internals, I wonder if the lack of any UI support in the ODBC driver allows it to ignore any Windows events/polling and thereby increase performance. My understanding is that VFP isn't interrupted anyways in tight loops (like you might expect with data manipulation) so that might not make a lot of difference.

One other intriguing possibility is having more than 1 CPU in the workstation. If the data access is synchronous (likely) it shouldn't make much difference - the app is going to wait for return of data either from the native engine on the same thread, or the ODBC driver on another thread. Asynchronous access could improve a lot, with the ability to hand it off to another CPU.

It's interesting to speculate why James got the results he saw, but we'll need a lot more details on his configuration and testing before we can make sense of it.