It is far simpler to implement the applications on a server and use Citrix so users can access it from any location. We do the same for our application where the server is somewhere in the Netherlands while the users are spread over several locations (in the USA, the Netherlands and Germany). This works like a charm.

The only thing sent over the network is screens because all processing is done on the server. Get a big server for this, this is a lot cheaper that to re-write (parts of) your application. Even access by dsl or telephone is acceptable because no data is crossing the network.

HTH,

Ron Brahma

>We have an application in VFE 7.5 and VFP 8.0 database. The application is slow for the remote workstations, and it gets slower as more users login. Often times the database crashes and most of the times it is the record count in the header doesn't match the actual number of records in the table.
>We are thinking about upgrading the database to a MySQL database to help speed up the application. Below I've put the configuration of the workstations and the network that I got from our network people. Please let me know if there is anything you can think of that can help us improve on the application speed.
>Do you think that upgrading to the latest version of VFE or VFP will improve anything?
>
>Thank you so much in advance,
>Bianca
>
>Network configuration
>What we have is three separate network locations connected via a VPN making for a psuedo LAN (which is really a WAN since none of the three networks are even in the same town). to each machine in each location the server where the databases are stored are merely a drive letter away (ie M:\POS\DATA).
>
>So, every copy of the program that runs looks for the data files on drive M in the \POS\DATA directory. The VPN box in the remote locations (yep, hardware VPN, not software) handles the translation of the letter M into the server in Burbank via the IP address for that server. Sounds a bit complicated but is really simple.
>
>The problem is the time it takes to translate the data request, send that request to the server, re-translate to a "local" SQL request, receive the answer, translate that to the requesting network/node address, transmit that back to the sender, re-translate it again into a "local" answer dataset and present it to the calling application. It is all this translation and transmission time that is messing up VFP to begin with.
>
>When we add the extra layer of translating the VFP SQL call into MySQL call and re-translating the MySQL answer into a VFP answer (the essence of an ODBC driver) I fear we will be adding more time to the whole process slowing things down even more. While we probably won't be corrupting the My SQL database due to the communication delay (like we are the VFP databases) we're not going to do the client much good by delaying an already slow response.