>The URL deals with data, not dev tools... FWIW, Visual Studio/VB/VC were not mentioned either.....<

Good point John.

>Hi Erik...
>
>I don't think replication and DTS are not the major issues here. Rather, replication and DTS are ways to make cached data available in other locations. The real issue rests with SQL-Server's ability to cache data. Here is an example, at one client, the first time you run a query, it may take 2 or 3 seconds to get 3 or 4 hundred records back to the client. The next time a query is run, it may take a half a second. Keep in mind that the query base is several million records. SQL-Server makes tremendous use of memory, much more so than VFP-Data. And, it is completely server-side.
>
>Mark, the originator of this thread...
>
>DBF's on the server cannot be placed in server-RAM. And, with that, DBF's will not scale in type of environment the URL you posted is addressing. As a development tool, VFP can create the necessary COM components. But, as a data source, VFP-DBF's don't scale and really don't have a place in that scenario...
>
>The URL deals with data, not dev tools... FWIW, Visual Studio/VB/VC were not mentioned either.....
>
>
>>Probably because VFP does not have built in support for Replication. DTS is a huge reason too. Without these, the developer would have to roll his own.
><