Ed,

As usual your replys on the system side of things are incredibly informative.

We are looking to have some people dialin to use SBT. We are going to have DSL links between the sites. We are considering PCAnywhere for 4-6 people accessing. Then possibly Windows Terminal Server when it gets beyound the 6.

What would be your suggestions for a 4-6, possibly 8-10 in the future, remote solution?

Have you heard of a problem of PCAnywhere not being able to connect to a site that is on the same router as you. I was by someone that they had problems connecting to another person if their DSL providers were the same and they went thru the same router.

TIA,

PF

>>One of my clients with a VFP app on a network in their office wants to ba able to dial into the network from a laptop at a remote location. Obviously there will be speed implications and I need to know what if anything can be done to reduce them to a minumum.
>>
>>i.e. should the exe file be on the laptop and access the system files on the network server without downloading the exe file from the server?
>>
>
>If it's an issue of a single user accessing the system intermittently from outside, a remote access package such as PCAnywhere will undoubtedly perform nearly infinitely better than attempting to run the application locally using a dial-in line to provide RAS access to the data at the remote site. PCAnywhere involves local execution of the application at the client site, with the connection between the remote laptop and the client site passing little more than keystrokes and screen updates - running using RAS access will entail passing data accessed across the dial-up connection, which even at 56Kbps, will be several orders of magnitude slower than data accessed across 10Mbps Ethernet. With perfect clarity of the phone line to achieve the best possible supported data rate and limited compressibility of the data, it would take on the order of 570-600 seconds, or roughly 10 minutes, to pass 4MB of data over the wire. Dial-in using traditional modems is assymetrical, using V.34 modem
>protocol outbound from a standard modem, and requires a specialized modem with a digial connection at the server end to actually use a 56K data rate protocol such as V.90, K-flex or X2 outbound from the server end; normal modem-to-modem connections without the use of specialized server-end modems would result in a V.34 protocol connection bidirectionally, with a 33.6Kbps maximum data rate, taking nearly twice as long to pass a similar volume of data. It will require far less time to run the application locally on the client site, accessing the data across the LAN and then passing screen update information and keystroke information across the dial-up connection.
>
>Even with a consistent, persistent remote connection, it will probably cost far more to redesign the application to use a client-server data model, implement a dedicated database server so that data for queries did not have to pass over the wire in detail and add the necessary hardware to properly set up full-time RAS either by dialup or VPN, to work with remote execution of the application, than to add a low-end box to the LAN to handle the dial-in requirement and run PCAnywhere. 33.6Kbps dialup access via packages such as PCAnywhere, while not nearly optimal, are capable of at least acceptable performance, do not require significant changes to be made to your application, and don't really insist on the use of a database backend to minimize data traffic for servicing queries. If the infrastructure for access via VPN to your environment already exists, PCAnyWhere version 9.0 is capable of making a VPN connection across the internet assuming that your proxy server will pass the
>required traffic.