>>I was going to make the same point about SQL Server performance. Properly tuned, it is VERY fast. John may have seen it on a box or network without enough memory, too much other load, etc.
>>
>>It was an eye opener a few years ago when I was hired to babysit a VFP 6 app that processed millions of transactions a day. My job (as a contractor) was to keep the VFP version running and make minor enhancements while two other guys rewrote the app in C / SQL Server. Having believed for years that "nothing runs like the Fox," it was quite a surprise when the SQL Server version ran rings around the VFP version (on the same hardware). And everything in the VFP version was optimized. Believe me, I checked.
>
>
>That really depends on what you do. VFP over a network won't run faster than SQL server. I'd expect SQL server to outperform VFP in many cases then.
>
>Also when doing SQL SELECT and UPDATE statements, I'd expect SQL server to be at least as fast in most cases, though there are specific instances where VFPs and OS caching might outperform SQL server.
>
>But in cases where you are using record oriented techniques like SET ORDER, SEEK(), SCAN, etc, you can run circles arround SQL server. But in this case, you really need to know what you're doing.
>

Are you suggesting I don't? <g> There is no deep dark mystery to SET ORDER, SEEK, and SCAN.

You say "VFP over a network won't run faster." Does this mean your scenario where VFP runs faster is with DBFs on a local hard drive? I didn't know even mom and pops did it that way any more.