Upgraded VFP 6 app to VFP 9 - Version 9 is running really slow
I am trying to upgrade a VFP 6 application to VFP 9. I have the version 9 app running on a handful of testing systems in the production environment. Users of the new version are complaining that it is running much slower then the old version. It doesn't seem to matter what OS the new version is on, it still runs slow. You can really see the slow down when trying to open forms that query larger amounts of data. The app users share a VFP view and SQL backend database.
What can I do to speed up the new version?
What can I do to speed up the new version?
ASKER
Yes. I have both versions running on the same systems and can easily spot the difference in performance. Both versions use the same ODBC connection to the SQL DB.
ASKER
Here's some food for thought... My development computer is located offsite from this customer and about 30 miles away. Using an ODBC connection from my development system via the internet to the same SQL DB, the same VFP 9 forms open faster here then they do within their local domain.
There is something in the app or supporting files located onsite that is slowing the new version down.
There is something in the app or supporting files located onsite that is slowing the new version down.
ASKER
This is not a VFP version issue. I transferred the shared files from our newish Server 2008 64 bit system to a Server 2003 32 bit system and both VFP 9 and 6 run ridiculously fast again.
I posted an issue awhile back about this same 2008 server where VFP print jobs would not pass through it as the domain print server. I set the 2003 server as the print server and the VFP jobs go to whatever printer I am trying to send them too and without issue.
What is with this 64 bit, Windows Server 2008 system that doesn't like VFP?????
Frustrating!!!!
I posted an issue awhile back about this same 2008 server where VFP print jobs would not pass through it as the domain print server. I set the 2003 server as the print server and the VFP jobs go to whatever printer I am trying to send them too and without issue.
What is with this 64 bit, Windows Server 2008 system that doesn't like VFP?????
Frustrating!!!!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I don't suspect 2008 server to be the reason itself. As you say a correlated problem was with printers, it seems the 2008 server is not connected optimal network wise. I'd analyze the route of network packages. SMB2 protocol is a problem, but not if te backend is SQL Server. Looks more like a firewall or hub issue.
Bye, Olaf.
Bye, Olaf.
I am voting for the Antivirus and/or opprtunistic locking (which should be disabled for VFP).
More info about oplocks: http://support.microsoft.com/kb/296264
More info about oplocks: http://support.microsoft.com/kb/296264
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Very grateful for all input - Thanks guys!!!
One test I ran last night was to copy my entire development environment into their domain, including the dbc. The same data environment that works fast from my office directly to their SQL server ran slow within their domain. I believe that rules out an indexing issue.
There is no firewall, software or hardware, within the domain.
A corporate wide anti-virus system is in place on all systems, meaning the Server 2003 system VFP runs quickly on has the same anti-virus policy as the Server 2008 system.
I am looking up the SMB2 topic - I assume you're not referring to Super Mario Brothers 2.
One test I ran last night was to copy my entire development environment into their domain, including the dbc. The same data environment that works fast from my office directly to their SQL server ran slow within their domain. I believe that rules out an indexing issue.
There is no firewall, software or hardware, within the domain.
A corporate wide anti-virus system is in place on all systems, meaning the Server 2003 system VFP runs quickly on has the same anti-virus policy as the Server 2008 system.
I am looking up the SMB2 topic - I assume you're not referring to Super Mario Brothers 2.
SMB2: samba protocoll 2, a low level layer of network communication. The issue really is OpLocks and Pavel has given a link to kb296264 above. The detail problem with SMB2 is, that you can't turn off Oplocks there, this was only possible in SMB (SMB1).
A Hotfix is here: http://support.microsoft.com/kb/2028965/en-us
This rather adresses stability, not performance, but often oplocks also cause an app to be fast for a single user, while it's reported unusual slow for multiple users, so that fix can help. Another workaround is revert to SMB and apply Pavels link to turn off oplocks.
Bye, Olaf.
A Hotfix is here: http://support.microsoft.com/kb/2028965/en-us
This rather adresses stability, not performance, but often oplocks also cause an app to be fast for a single user, while it's reported unusual slow for multiple users, so that fix can help. Another workaround is revert to SMB and apply Pavels link to turn off oplocks.
Bye, Olaf.
Oh, and actually SMB is called server message block, not samba protocol. I was just thinking of Linux, as there a samba server can replace a windows server in some aspects, eg act as a domain controller and file server.
Bye, Olaf.
Bye, Olaf.
ASKER
The issue has turned out to be a DNS problem with the ini files where local systems were told how to access the shared data.
\\CorpDomainWAN\Branch\All
Any follow up thoughts?
You three were all helpful. Any recommendations on point distribution for this issue?
\\CorpDomainWAN\Branch\All
Any follow up thoughts?
You three were all helpful. Any recommendations on point distribution for this issue?
Is the behavior same when you map the UNC as a drive letter?
ASKER
The new version works just fine with the ini files set to point to a drive letter (O:\Apps\VFP\data).
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
If the application uses data from the backend database then the backend speed is probably the bottleneck. The view definition could also have some influence.
If the application uses local DBF data then its speed depends namely on correctly designed and created indexes. You have to identify what queries and commands are slow and create appropriate indexes which could optimize data access.
Are you testing both applications on the same data?