>This is all changing, however. The client would be happy to have a centralised system that (a) is based on a central server at HQ, (b) is accessed by PCs at any number of locations, (c) and whose data can be extracted for analytical use by other systems.
>
I'm a big fan of WWW clients and VFP backends on the server. That way you get (b) solved in a particularly excellent fashion along with the rest. Security issues have been dealt with pretty well. And performance, well most people are used to the performance on the internet. If you want to get dedicated lines you can have a truely fast application.

>The xrux is speed: is a VFP application capable of running on a central server with (presumably) the exe file sitting on remote PC locations (up to 40 kms away) and capable of providing a decent response time? I understand that data transmission speed is critical but I am trying to get a feel for what the minimum speed I should specify to the user before proceeding.
>
Before you can answer that question you need to look at how the users interact with the remote data. If all they need to do is bring down a record at a time for display then ordinary telephone line speed should be good enough for that task. If updates can be collected in a queue on the client before updating to the server (batch data entry) then ordinary telephone lines are also probably sufficient. If you need fast access to multiple records on the remote server during data entry then you will need something faster. This is all my opinion here, by the way!

I think speed is a very soluable problem. Indeed the 'older' the software it is the more soluable. For example I'm looking at an application that was originally written in FoxBASE. It has no grids, and only three browse windows. Because of that it only rarely needs to pull more than a handful of records across the telephone lines. Performance is far more an issue if you have lots of picklists, drop down combo boxes and the like.

The difficulty comes up when you require both fast data entry and the use of server tables at the same time. If you have to help the user enter in insurance codes with a combo box then you need to drag those insurance codes local somehow. Other people on this thread suggested bringing that sort information locally and synchronising it nightly. From your comment that the sites currently don't share data, I suspect that this is not a problem.

>SQL only comes into it because the client currently uses SQL server linked via pump engine to Lotus Notes, and they are keen on my system feeding into their SQL server. I can easily fight SQL server off, as long as I can prove VFP will work over a WAN.
>
VFP definitely works over a WAN, there are many proven approaches.

>Your comment about VFP and a Net based application is interesting as well. I would like to come back to you and pick your brains at a later date on this if I may.
>
Don't be scared off from writing a web interface: it's not that hard as long as you design the interface to do what it's good at rather than what VFP is good at. Typically in a web interface one doesn't line things up by pixel, there is really no absolute placement of items on the screen. This makes it harder to a get a screen to look exactly the way you want it to all of the time. On the other hand it is much easier and natural to design user interfaces that show a lot of information or show conditional information than in VFP forms. It's also easier to allow the user to print what they see -- they just hit the print button on the browser. Web interfaces also encourage you to hyperlink things. Of course one can do it in a VFP interface but its a little harder and the user is a little less used to the idea. You can, for example have the user doubleclick on a grid element in VFP and bring up a new form, but that would surprise an inexperienced user. In a web interface the item is underlined and users *know* that they can click on underlined text and go somewhere.

The chief disadvantage with a pure web interface are:

a) lack of some UI features. Toolboxes, menu drop downs and the like don't exist in HTML.

b) lack of a visual design environment if you use VFP to generate the HTML code as in West Wind. To get started you can use front page and crib the HTML it spits out to make your screens but it's fastest just to code in HTML.

b) grids: I have never really tried to solve data entry grids on the Web, it can be done but I haven't had the need to yet.

c) state programming. Every hit on the webserver is independent, you must reconstruct the users environment every time they access the server. This has far reaching consequences.

d) Difficulty enforcing data dependencies on a data entry screen.

e) Focus (cursor) is harder to control. You can't easily skip a field because another field has been entered. (This is f) above really)

f) Printer control, and control of the hardware on the computer in general. We use Adobe to create visual foxpro reports in pdf format which works, but we also have a VFP client at some of our sites because we can't get the dot matrix printers to work perfectly without @SAY ...GET.

Of course by using java or something like that you can do all of these things. In a way web programming is a return to less sophisticated interfaces, which frankly can speed up development time.

To summarize, a web interface sucks if you need high thruput data entry because you can't do (without Java/Javascript) many of the time saving tricks that you can with a VFP interface. If you want the user to scan an insurance ID off of a barcode and automatically pop to the patient information with the cursor sitting at right spot then you are no longer writing in HTML.

On the other hand web interfaces are great at displaying lots of information, and particularly document information. They are also much better than VFP interfaces if you have a lot of users who are not dedicating their work time and computer to your application.