Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Slow Speed and upgrading possibilities
Message
 
 
To
All
General information
Forum:
Visual FoxPro
Category:
Client/server
Title:
Slow Speed and upgrading possibilities
Environment versions
Visual FoxPro:
VFP 8
OS:
Windows 2000
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01150575
Message ID:
01150575
Views:
55
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.
Next
Reply
Map
View

Click here to load this message in the networking platform