Trouble-shooting a Visual FoxPro application
If you're having problems with a VFP application, these solutions might just be what you need.
By Dan Macleod
I recently received an anxious phone call from a local office supply firm. The company uses a large Visual FoxPro (VFP) application to control its business. Or rather, it's trying to. Unfortunately, the application is plagued with bugs, poor performance and frequent crashes, almost to the point where it's unusable. Could I help?
My first reaction was to ask if they had contacted the people who wrote the application. Yes, they had spent long hours discussing the issues with the vendor's help desk. At first, the people there were supportive and helpful, but they eventually said that none of the problems were of their making. The fault, they claimed, lay somewhere in the users' environment, and they were unable to give any more help. That's when the company called me.
Naturally, I accepted the assignment. Now, after several days of observation, diagnosis and research, I've solved all the major issues. I offer my findings here in the hope they will be of benefit to others. If you are seeing any of these same problems, I can't guarantee that these solutions will work for you, but they should at least give you something to think about.
Problem #1: Application goes to sleep for a while, then wakes up
Symptoms: The application was frequently freezing for a short period, ranging from about ten seconds to a couple of minutes. This always happened on system startup, and often when opening a form or launching a report. The application would then resume normally.
Diagnosis: This is a classic symptom of an over-zealous anti-virus (AV) program. The program scans the many files that make up the application's Visual FoxPro database whenever any of the files is opened. Because some of the files are very large, and because they are typically opened and closed many times during a session, the scanning time can quickly become unacceptable.
The silly thing is that none of the FoxPro database files need to be scanned, as they can't contain executable code.
Solution: Tell the AV program to refrain from checking the following file types: DBF, CDX, FPT, DBC, DBX and DBT.
Problem #2: "File access is denied" error
Symptoms: The application occasionally crashed with this error, usually on system startup. On monitoring the file usage, I could see that it usually happened part of the way through opening a series of abut 25 files, but not always at the same point. Despite what the wording of the message suggests, none of the files was being opened exclusively.
Diagnosis: This is opportunistic locking rearing its ugly head. In brief, opportunistic locking (also known as oplocks) is a Windows feature designed to improve the performance of client-server systems. When a workstation asks to open a file in shared mode, the file is in fact opened in exclusive mode, which is faster. If another workstation then needs to open the same file, the system is supposed to release the exclusive lock that was given to the first workstation. But with simple file-based databases like Visual FoxPro, this sometimes fails to happen, hence the "access denied" error. (For more information, see this Microsoft Knowledge Base article.)
Figure 1: Use Addsum OpLockSet to
control opportunistic locking.
Solution: Disable opportunistic locking. This needs to be done for all workstations and servers on the network. You can do it by editing certain registry keys (described in the article mentioned above). Or you can purchase the low-cost Addsum OpLockSet Utility which does the job for you through a user-friendly interface (Figure 1).
If you adopt this solution, I strongly recommend that you do it in a carefully controlled trial. And be prepared to reverse the action if necessary. Disabling oplocks could adversely affect the performance of the network as a whole, especially if you are also running a true client-server databases such as SQL Server.
Problem #3: "Class definition xxx.yyy is not found" error
Symptoms: This error frequently occurred at a certain point in the application, but only on a few workstations, and not consistently (xxx.yyy in the above heading is the name of the class definition that was not found).
Diagnosis: In general, a class definition whose name is in this form (two or more elements each separated by a dot) is an external component, such as a DLL, COM server or ActiveX control. The error is triggered by Visual FoxPro's CREATEOBJECT() function when it fails to find the component in question. This can happen either because the component is not physically present, or it is present but not properly registered.
But that didn't explain why the error was only occurring intermittently. You'd think that either the component was all present and correct, or it wasn't.
It turned out that - for a reason I never discovered - the person who installed the application did so by using Remote Desktop to log into the server. So the component was properly installed, but it was registered on the server, not the workstation. What's more, the user sometimes used Remote Desktop to actually run the application (again, I don't know why). On those occasions, it ran normally. It only failed when they launched the application from the workstation.
Solution: Always install a Visual FoxPro application from the workstation. If you want to place the executable directory on a server, that's fine. But navigate to the server from the workstation, not by using Remote Desktop.
Problem #4: Program crashes after producing a PDF
Symptoms: Whenever users output a report to a PDF file, the application would crash, typically with a "File xxx does not exist" message (where xxx stands for a filename). The crash sometimes happened immediately after generating the report, and sometimes when the user next opened a form.
Diagnosis: This is caused by a somewhat strange interaction between Visual FoxPro and the PDF driver. It happens when the following sequence of events occurs: the VFP code starts a report; the user chooses a PDF driver as the destination printer; and the driver prompts the user for a filename and directory for the output file. When that happens, the driver changes the default directory, as seen by VFP, to the one selected by the user - and fails to change it back when it has finished. Later, VFP tries to open a file in what it thinks is the default directory, and naturally can't find it. (This isn't a bug in a particular PDF driver. I've seen exactly the same behavior with several different drivers.)
Solution: This is one for FoxPro developers to fix. Before producing any report, save the path to the current default directory to a variable, and restore it after the report has finished. You need to always do this with all reports, because you never know when the user is going to choose a PDF driver as the destination printer.
Problem #5: Printed output goes to the wrong printer
Symptoms: When a user tried to print a report, the output would always go to the same printer, regardless of which printer the user specified. This happened consistently with certain reports, but never with others.
Figure 2: Uncheck this option
in the report designer.
Diagnosis: This was an easy one to solve, mainly because it's such a common VFP problem.
The FoxPro report designer has an unfortunate tendency to store the so-called printer environment within the report. The printer environment covers such items as the paper size, orientation, paper source, and - crucially - the destination printer. These parameters then get applied to the report whenever it's printed - regardless of what settings the user makes in the Printer dialog.
Solution: Again, this is one for developers to fix. You need to ensure that the report designer does not store the printer environment with the report, and to remove it from any reports where it's already stored.
For programmers using Visual Foxpro 9.0, that's simply a matter of unchecking the Printer Environment option on the Report menu (Figure 2). You can also change the default setting of this option from the Reports page in the Options dialog. But if you're using an earlier version, you will have to resort to hacking the actual report file (the FRX file). Several articles are available that will tell you how do that; see for example Controlling report settings at run time.
I was able to solve these problems, mainly because I had seen them all before - although some are more common than others. If you are running a Visual FoxPro application, you might come across some of these same issues. As I said at the outset, I can't be sure that my solutions will work for you as well. But I hope the information I have given here will at least help you in your own trouble-shooting efforts.
Please note: The information given on this site has been carefully checked and is believed to be correct, but no legal liability can be accepted for its use. Do not use code, components or techniques unless you are satisfied that they will work correctly with your sites or applications.