On 10/19/2014 8:39 AM, Wes Wilson wrote:
Hello again, Wes.
Reference our brief telephone conversation last week (while you were in
TX). I finally had some time to sit down and send you a
follow up email request. I have two immediate issues for you:
1. VFP9 Performance
Our software (an ERP), which is written in VFP9, performs very poorly
over the network from a virtualized Windows 2012 server to a workstation
running either Windows 7 or Windows 8. There is a big delay opening
some screens. However, when our software is run directly on the
server, or over RDP, the same screens open and perform 10 times faster,
or more. Something is making network performance very poor for the
VFP software. There are no issues with other softwares, by the
way.
The network is 1Gbps. No anti-virus software is running. The
workstations and server have plenty of RAM and horsepower.
2. VFP9 crashes
At a couple of different installations, some users run the VFP9 software
directly over the LAN, while other users simultaneously run the VFP9
software via terminal services (RDP). The RDP users randomly
experience crashes, while the LAN users have no such problems. The
RDP users connect to a terminal server (Server 2008).
When the crashes happen, the Event Logs show two errors, one right after
the other:
· Event ID 1000 (Application Error).
The faulting application is our VFP9 software, and the faulting
module is one of the following: VFP9R.dll; or mscrv71.dll; or
ntdll.dll; or "unknown"
· Event ID 1005 (Application Error).
The note states, "Windows cannot access the file for one of
the following reasons: there is a problem with the network connection,
the disk that the file is stored on, or the storage drivers installed on
this computer…"
The IT Specialists have tested and re-tested the network infrastructure
and its components. No problems are ever detected.
Both of these issues seem to point at VFP9 having problems over modern
network connections.
Has anyone else had, or heard of problems like this?
Wes: Frank Cabazon helped me regarding this exact problem. I have a
lot of VFP 9 applications using the Visual Maxframe Professional
framework. If the application was installed on a workstation and
accessing files on another computer or server there are some registry
entries that will fix this. I set them on the workstations and the
server. (in many applications the "server" is another computer not
running a server OS)
They are:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\OplocksDisabled
= 1 (default = 0 or not disabled)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\SharingViolationRetries
= 0 (default = 5)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\SharingViolationDelay
= 0 (default = 200 milliseconds)
You may have to enter the Parameter key and almost always have to enter
the other DWords.
As best I can tell, Microsoft uses oplocks to help their Office products
open faster and only affects things like DBF files and Access files.
It also appears that accessing a DBF on another computer always throws
sharing violations even if they are shared on both ends.
Adding these registry entries on all computers has solved the problem.
I did also discover that the second and subsequent log ins to VMP
prompted a VALIDATE DATABASE in a shared mode that really slowed things
down.
Point being that after entering the registry entries, look at the
bottlenecks and see if you can improve performance.
I can't thank Frank enough for helping me solve this. It made the
difference between a frustrated user and a happy user!
HTH
--
Jeff
Jeff Johnson
[email protected]
SanDC, Inc.
(623) 582-0323
SMS (602) 717-5476
Fax 623-869-0675
Visit our forum at www.san-dc.com/forum
Register and join in the discussion
www.san-dc.com
www.cremationtracker.com
www.agentrelationshipmanager.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
