>>>>>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.
>>
>>
>>Thanks Al!
>>
>>that is very well put and clarifies things a lot for me. Do you have any recommendations in terms of where I can find more about configuring Terminal Services and specifying hardware requirements for it? Are there any alternatives besides TS (is it now called RDP?) and Citrix?
>
>I haven't worked with RDS on Server 2008 but it looks like there are some good resources here: http://technet.microsoft.com/en-us/library/ee817089.aspx?SA_CE=VIRT-IPD-WEB-MSCOM-2009-12-02
>
>Alternatives: VFP running in file-server mode against DBFs is very demanding. I wouldn't even think about remote session hosts that aren't Windows-based or that don't give you true, licensed Windows sessions for your users (i.e. forget WINE on Linux).
>
>TS/RDS and Citrix are the two biggies in the space. I know there is at least one other, I checked into it briefly for another client who was contemplating hosting QuickBooks via TS. I spent about 15 minutes looking for it but I can't for the life of me locate the info I had. It was significantly cheaper than TS but not free, and you need a reliable, well-supported product. TS/RDS isn't that expensive; you could easily burn up its entire cost, or more, on some "less expensive" alternative that causes problems.
>
>Besides, with all the $ you're saving not having to re-write your app, you can easily afford the real thing :)

Thanks again. My application can switch from DBF to SQL Server by just setting a configuration switch so there isn't any cost associated with that and it is designed to limit data flow over the network. I guess if the cost for TS/RDS or Citrix is too much for the client we can look at the VPN and using SQL Server and see if that will be fast enough for them.