>>>>Thank you, Hank. I decided to cancel trying to find a Cloud solution for deploying my app. What got me looking into it is a couple of prospective customers didn't want to have any IT work done and put it all on the vendor (me). Next prospective customer asks for it, I will just say No. If they cannot afford or cannot do IT, I am out of their picture.
>>>
>>>It is feasible but not when executing with remote dbf tables. You need to put everything over there - your exe, tables etc - and have them access it via terminal services or citrix.
>>>
>>>Alternately, you run locally but keep SQL in the cloud. I've seen that done, and depending on how much you pull down or push to server, may work just fine. The nice part is that a VFP app isn't too demanding in today's terms (processing power etc) so no special hardware is required locally, even six year old boxes should run it fine, and you don't have to reserve that much processing space per client on the server. The bad part is that if you're pulling huge cursors from SQL, you may need to wait. But nowadays the speed of the net is up to video streaming, so just pulling a dozen thousand records off a server can't be too slow.
>>
>>First, terminal services and citrix are out of the question. I don't know these technologies and some customers do not want to have IT involved at all (or, I should say, that IT does not want to be involved). But from your message I get one thing. If I have SQL Server in the cloud and put everything, executable, meta data, configuration, etc. on each client PC, then - theoretically - they don't need a VM server. Which, of course, makes maintaining the application a little challenging (every update, each client PC has to be updated). But it is feasible. I just don't know if it is worth the pain to go through all these jumping through the hoop.
>>Thank you for your input.
>
>As it happens I work with a VFP/SQL Server app where both scenarios are supported:
>
>- Local VFP app with remote/cloud SQL Server
>- RDS (Terminal Services) option
>
>In addition to regular LoB functions this app also stores various document types within the SQL database itself (rather than linking, for regulatory/compliance purposes). These documents are typically at least 1MB and are often 10MB or more.
>
>Dragan is right, for the normal LoB functions not involving these documents the traffic to/from a remote SQL server is not large and performance can be surprisingly good. However, if they want to view a document, it has to be pulled through the public Internet. The limiting factor is almost always the uplink speed at the remote SQL Server, which a lot of people don't seem to care about. The remote server might be on a 25 down/6 up connection. A 10MB (80Mbit) document would take 13 (80/6) seconds to download at theoretical maximum performance, in practice it's more like double or triple that time. It's do-able but painful in practice.
>
>Maintaining apps locally can be a PITA. In our case we also require MS Office to be present, you can run into nasty, hard to debug issues if a local machine's installation of Office is less than pristine. Plus all the other issues maintaining local workstations of which you're no doubt already aware.
>
>Another factor with a remote SQL Server is these days sysadmins on the host side will not let you just open a firewall port and forward it to a SQL server instance. It's asking for trouble - hacking and DoS attempts. You will need to install and configure a VPN at both ends and tunnel your traffic to/from the remote SQL server through that.
>
>The RDS option has a couple of pain points:
>
>- If users have local documents which they must embed in the SQL server, they have to upload them to the RDS host first (doing it directly from a host-visible local drive is not reliable). However, that's a one-time thing: once they've done that and embedded the document, subsequent retrievals are instantaneous (faster than LAN) because the SQL server and the RDS sessions are all on the same physical computer
>
>- Some of the documents are things like detailed maps, drawings, aerial photography etc - highly graphical. Viewing these through an RDS connection is highly dependent on the uplink speed at the host, with complex graphics you have to be careful navigating through documents (use pageup/pagedown instead of scroll wheel etc) and you often see some raster-style screen redraws. By default RDS sessions are only 16-bit colour, so if you need to see documents in 24-bit or deeper you have to accept slower screen refreshes. If a user has to work extensively with a highly graphical document they can download it and view it locally. Still, RDS/RDP is highly refined and efficient. One installation has only a 5Mbit down/1Mbit up link at the host side but performance for almost all functions is nearly good enough to make you forget you're working remotely, and even viewing graphical documents is still quicker than having to download them.
>
>It's worth pointing out that the RDS option lets you access the app using any device that has an RDP client. Various non-Windows computers, as well as tablets and some smartphones have that capability. That could be a strong selling point into new environments.

Hi Al,
Thank you very much for a detailed description of your project. For me, to jump through all these hoops so that just to relieve the company IT from doing anything (and by the same token, blame me for any downtime/issues), is not worth it. The entire project (the prospective customer that I mention at the top of the thread) would be about 12K. I think 10 years ago I would have jumped into this, learning, testing, trying. But not now.
Thank you for your helpful input.