>>Save any headaches, go straight to Terminal Services.
>>
>
>HI Neil,
>
>so you do not recommend using a VPN and SQL Server? Has this been unsuccessful for you or someone you know in the past?
>
>Why do you recommend Terminal Services rather than other options which are apparently cheaper, easier to configure and faster like Hamachi?

LogMeIn/Hamachi:

Cheaper - probably yes
Easier to configure - maybe
Faster - probably not

With remote access, "speed" mainly depends on minimizing the amount of "stuff" that has to travel over the wire.

I don't know what your Internet service is like in Trinidad (or maybe you're working with clients located somewhere else?) but using typical North American service as an example, it's asymmetric. Download speeds can be fairly good (20Mbit/sec or even more) but upload speeds are often capped at 0.5Mbit/sec or less. Compare that to LAN speeds, which today are 100Mbit/sec minimum, and often 1,000Mbit/sec (gigabit).

This is important because if the data are, say, at your site, and remote clients are connecting to you, anything they download from you is limited by your upload speed.

Worst-case scenario is direct DBF access, as others have already pointed out. This is dead-slow to the point of being pretty much unusable, and since a WAN/VPN is not very reliable you're vulnerable to disconnects, data corruption etc.

Accessing a SQL database through a VPN can be a lot better as long as the client-server architecture is exploited fully to minimize traffic i.e. only return minimal result sets to the remote clients. Even some commercial applications such as SAP Business One use SQL Server only as a dumb data store and do all processing on the workstations, so it requires a lot of network bandwidth. Even if you do architect the app to minimize network traffic, there will still be cases where you have to send significant chunks to the client (perhaps reporting, etc.) and over a slow upload link response will seem poor.

Minimum network traffic is usually achieved using remote control. The only traffic going back and forth is keystrokes, mouse actions and screen updates (and optionally, remote print jobs). Modern remote access software is highly optimized and with a North American-standard broadband connection the response is so good you sometimes forget you're working remotely. LogMeIn remote control (not Hamachi VPN) is one example, Terminal Server is another. The main difference between LogMeIn remote control and TS is that the former requires one physical or virtual computer per remote user, while TS is more scalable and can support many remote users per TS server.

Remote control is much more fault-tolerant than an app run over a VPN. If the VPN goes down your remote app has to deal with a broken connection. With remote control, your app does not care if you're connected or not. I have some clients I support remotely where I periodically need to run a process that can take a couple of hours. In those cases I connect, start the process running, purposely disconnect (the process keeps running on the host) and then reconnect to my session a couple of hours later to see how it's doing.

If you go the remote-control route you don't need to change your app at all, you can continue to use a DBF back end. As far as your app is concerned, the network is local, fast, and reliable.

You need to get a good idea of how many simultaneous remote users you'd need to support. You might find a client says "I want 3 sites times 1 machine per site". But, after using it for a bit they like it so much they say "It works great! Now I want 10 sites times 5 machines per site". A Terminal Server-type remote-access solution is by far the most scalable answer to that sort of scenario.

The biggest drawback to remote control is that if a network/Internet connection goes down, remote clients have no access to the application. This is not tolerable in some environments such as retail POS; it's not acceptable to be unable to sell product because a network connection is down. For that sort of need the app needs to run locally, and then as you pointed out earlier you'd need to set up some sort of replication or updating amongst sites.