>>It's been a couple of years since I last looked into it but my understanding is 100Mbit connectivity is pretty good (and expensive!) for either MAN or WAN. It would be nice to think that a typical VFP app would run decently at that speed, but in practice a link like that will have much lower actual speed than a 100Mbit LAN link for a typical user:
>>
>>- Dedicated site-to-site links tend to be *very* busy. As a result, even with no traffic management in place, your traffic will contend with many others for use of that link. Your real-world throughput will be a fraction of the nominal value
>>
>>- There may be traffic management in place. You may be on a network segment at your end that's limited to using X% of the total link bandwidth. And you may be contending with other users on your network segment for use of that X%
>>
>>- Some WAN/MAN links transparently use hardware compression to increase the apparent bandwidth of those busy connections. This might actually help your app, as some DBF type files can be compressed as much as 10x. On the other hand, this will hurt latency due to the time involved to compress and decompress your traffic.
>>
>>- Whether hardware compression is in use or not, there will be a lot more network latency over a MAN/WAN link than over a LAN. This alone can be perceived as slowness in apps, especially for small queries you would normally expect to be very quick
>>
>>The quickest fix in your situation would be to use Remote Desktop or similar, rather than pulling your DBF/CDX/FPT data directly over that 100Mbit link.
>
>Thank you very much for the detailed explanation. I also thought to suggest to the IT to give this user a RDT access to the server.

Al has already gone into more detail than the answer I considered ;-) But set up a VM inside the net WAN connects to - better isolation, you can move that to other PCs or servers - and then RD into that VM. Speed will be good enough, as VM accesses tables within the server net.