Since we changed the original subject, let's move it to another thread. :)

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

So, here you mean that the VFP server in this case actually receives the query from the client app, passes it to SQL-Server, then creates the ADO from the result set and sends it back to 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...

I assume you mean the case of VFP file-server app working over the WAN, right? But in case of VFP client-server app, what about the difference in speed of passing ADO in the architecture you described, and just the recordset from SQL-server (both over the WAN) ?

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