Actually, I was making the case for how you could get some scaleability with accessing VFP data over a wan. If you are accessing SQL Server, you don't run into the problems with a file-server based system like VFP. In the VFP case, to get some scaleability, the server-side COM Components are almost a necessity. With SQL, while it would be good from a design standpoint to have the abstraction, SQL Server itself would still only send the result to the client. With VFP data, you get other elements sent to the workstation besides the results set. And when doing this over a WAN, can be excruciatingly slow...

Remember, VFP's slowest operations are opening and closing tables....


>Now I see what you are talking about. Sounds interesting. So, if I understand you right, VFP server talks to SQL server database on the same PC and the resulting ADO (or XML?) goes back over the WAN to some kind of thin client. How much faster is it if compared with VFP client app sending the SQL query to the SQL server (with no VFP server there) over the WAN? Say, in both cases the result set has the same number of records, and it goes back as ADO on first case and as VFP cursor through ODBC in second case?
>
>
>
>>I have a 400 million row table that I need to query over a WAN.......
>>I need replication services....
>>I need integrated security.....
>>etc....
>>
>>With respect to queries over a wan and VFP data, the best way I have found to do it is through RPC's.. Bascially, having a VFP server ON the server that has the data, and remotely activating that server. The server in turn opens the data ON the server - no traffic accross the wire. The VFP server in turn, returns the result to the client via ADO recordset or some other mechanism...
>>
>>How's that...????
>>
>>>>In many cases, SQL-Server beats the pants off the VFP engine.
>>>
>>>And those cases are...?
>>>:)