>>>>Personally, I do not see a very good case for having huge result sets that need to be processed in VFP. The last huge VFP-database I got lies many years behind me. But again I realize there might be certain cases that might justify doing that. However in general it should not be done. SQL server is cheap, robust and fast.
>>
>>We work with static lookup tables with tens of millions of rows. Not live data. We could do intensive processing at the database server, or we could cache dbfs locally and use the power of a modern Windows machine to crunch through it with zero impact on other users or server. We prefer the second option that allows us to do real-time checks that some other vendors insist is impossible.
>
>And if you and the clients are satisfied with that approach, that's great.
>
>The point is that SQL Server can accomplish the same thing - which is something you cast doubt on, in your prior message.

It depends on the meaning of "real-time".

Even if you have a back end that's so fast its response time drops to zero, there's some latency getting the request to the back end and the response into the client's address space. That may be insignificant if you're looking for a response time of, say, 250 - 500 milliseconds. But there are some scenarios such as "real-time" lookups/autofill while a user is typing in a data entry field and which has to respond to each keystroke.

If the client is fat enough then a large VFP lookup table can be cached either in in-process RAM or in the Windows disk cache. A straight indexed SEEK will be pretty fast.

It would be interesting to test, but my gut feel is that local SEEK can be faster than the latency of going out to even an infinitely fast back end across the network. If so that could make some "real-time" operations feasible that are not possible with a model where you have to keep going across the network to the back end.

OTOH you could achieve something similar with a SQL back end if, in VFP, you're willing to load a cursor or remote view that downloads the entire lookup table. You'd have to fill the cursor once and index it (maybe at start of the app) but after that it'd be essentially the same as using a static local indexed table. So it would cost some time in application startup. Having a fast in-memory backend would probably help a little but network latency and bandwidth might be more serious bottlenecks.