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

Just wanted to mention...

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

Well, aside from specific instances with SET ORDER, SEEK and SCAN, which really depends on a number of factors like network speed, chaching and its SQL server equivalent implementation, VFP will run better than SQL server on a local harddrive in many cases, just because you cut out the network component.

Sure, there are heaps and heaps of mom and pop apps that run locally. If it were not for the accounting type of apps, the chash register programs, etc, there are a lot of VFP apps running on citrix or TS which technically run locally.

Then, of course there is a component of different design: Datamunging on the client. VFP is equipped excellent for datamunging. This means that you can get the raw info from the SQL server and post process it at the client. This will avoid datamunging on the server in lengthy SPs in a set oriented manner. SQL server is not as equipped as VFP for this type of processing and this typically consumes more resources and more important, the bottleneck now is centralised on one point: The SQL server. Imagine that 10 clients run the same datamunging procedure at the same time. In the case of SQL server, your server will be heavily stressed. In the case of offloading the needed data from the SQL server and postprocess it one each individual client you've got a much better performing situation (assuming that the offloaded data is not too large).

So, again, it depends from what angle you look at it.

Walter,