• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1632
  • Last Modified:

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?
0
woodwyn
Asked:
woodwyn
  • 6
  • 4
  • 4
  • +1
3 Solutions
 
pcelbaCommented:
There is no major difference in the data processing speed between VFP 6 and VFP 9.

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?
0
 
woodwynAuthor Commented:
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.  
0
 
woodwynAuthor Commented:
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.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
woodwynAuthor Commented:
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!!!!
0
 
CaptainCyrilFounder, Software Engineer, Data ScientistCommented:
I am not sure if this will help, but for sure they helped me in speeding up applications in my cases:

Backup and Delete foxuser.dbf files and try again
Disable all anti-virus and firewalls and try again
Reindex the databases and try again

I have VFP running on 64-bit Windows Vista Ultimate and it's superbly fast. I even connect to a database from Beirut, Lebanon to San Francisco and it's blazingly fast.
0
 
Olaf DoschkeSoftware DeveloperCommented:
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.
0
 
pcelbaCommented:
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
0
 
Olaf DoschkeSoftware DeveloperCommented:
"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."

If that is the case, it could be antivirus, yes, SMB2, I don't know if VPN would cut off that problem, could be. I'd also check via ROUTE PRINT from a client at their domain to the server, if there is no loopback or other network problem you remove, when you come from off site via VPN (I assume you com in over VPN).

Bye, Olaf.
0
 
woodwynAuthor Commented:
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.
0
 
Olaf DoschkeSoftware DeveloperCommented:
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.
0
 
Olaf DoschkeSoftware DeveloperCommented:
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.
0
 
woodwynAuthor Commented:
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\AllData\APPS\VFP\data became \\LocalServerName\AllData\APPS\VFP\data.  The CorpDomain UNC worked for the last 6 years and continues to work with the VFP app in version 6, but is really slow with the version 9 app.  

Any follow up thoughts?

You three were all helpful.  Any recommendations on point distribution for this issue?
0
 
pcelbaCommented:
Is the behavior same when you map the UNC as a drive letter?
0
 
woodwynAuthor Commented:
The new version works just fine with the ini files set to point to a drive letter (O:\Apps\VFP\data).
0
 
pcelbaCommented:
OK, then there is a problem with some UNC pathes in VFP 9 and nobody will help probably...
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 6
  • 4
  • 4
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now