Today's fun: VFP Memory Limitation
One of my clients called me with a problem with one of their VFP 6 applications crashing. The application has been running in 30 locations for 10 years with very few changes. I did not develop this particular app, but did mentor the original developer and helped with the design. It is used by engineers. At the site it was working on one computer, but not the other three. The error is one of the more common ones: Function argument value, type, or count is invalid. (11)
The IT department no longer has fresh VFP expertise because they have moved on to a new development platform. They gave me a call hoping I could fix it immediately so the engineers could keep on working. They brought the data back, but could not reproduce the problem.
Fortunately the Visual MaxFrame error logging is decent. Unfortunately the customer does not compile in the debug code so I could determine the program, but not the line number or the actual code. I dug in using the error log and traced the code to the SYS(3050) command. In the startup of the application a call is made to a procedure that sets the amount of foreground memory to a percentage of the overall memory available on the machine. The calculation uses Windows API calls to get memory on the machine and then works through a formula. In this case we are talking about three new engineering workstations and they were loaded with 4GB of physical memory. The program was determining it could have a little more than 2GB of RAM. The VFP Help file does not indicate a limit even in the latest version, but apparently there is one.
So the lesson learned today is: do not to allow the setting of the SYS(3050) function be strictly calculated. I added code to pick the minimum of the original calculated amount and something less than 2GB. It is the first time I have used the VFP MIN() function in a long time.
I never hit this problem because I have a configuration item with the amount of memory to set. I know several developers use a formula to determine the amount of memory to allocate to VFP. If you are one of these developer you might want to check your formula to see if large amounts of memory could trigger this error.
Labels: VFP
7 Comments:
Such a calculation routine is absolutely useless. Set the fore- and background memory to a fixed value of 32 Mb (yes, not more!) and VFP wil hum along. You may want to dig out the speed tests from Mac Rubell in FoxPro Advisor from 1997/1998, they are stil valid. More memory isn't always better. Remember: the VFP dataengine was developed when we had only a handful of RAM and we stil have been working with Gigabytes of data.
I had to look up the setting I am using and it is 64MB. If I recall correctly I used Mac's findings to determine the setting. Those were great articles, thanks for mentioning it here.
Hi Rick,
I'm pretty new to foxpro and have been asked to look into some issues that have come up on a couple of existing foxpro 8.0 applications, that were developed around 10 years back or so.
These applications load data from several text files into a sql db. A lot of complicated processing happens within the program, with the use of several cursors. This load program fails with the following error -
Error (1190) in RULE105_rule105 on line 2982 message File d:\empower\temp\2moo00bz.tmp is too large
So, I looked into the temp folder and found that it is creating temp files greater than 2 gb, while doing inserts into some of the cursors. So, I did some googling and read that decreasing the buffer foreground memory might help. So I went ahead and changed the values as follows.(in the idea that foxpro might create smaller .tmp files) It actually worked for one of the apps. But the issue still exists with another app. I've been on the internet for the past few days trying to find articles related to how foxpro does memory mangement and I bumped into your blog. Could you tell me if this approach absolutely does not makes sense at all? or if there is any way we can tell foxpro to create .tmp files less than 2gb? Or if you have any suggestions?
Existing Values:
Buffer Foreground Memory: 536870912
Buffer Background Memory: 134217728
Changed Values:
Buffer Foreground Memory: 268435456
Buffer Background Memory: 67108864
Also tried to reduce it further to the following. But it's not helped so far.
Buffer Foreground Memory: 67108864
Buffer Background Memory: 16777216
Thanks,
Suganya
Suganya,
The 2GB limit is a hard limit for DBF files, which cursors are. The memory limit will not fix this. Only reducing the amount of information into to cursor will help avoid the limit. You can reduce the number of columns, the width of the columns, or the amount of rows stored. You can also partition the cursor into two cursors.
My recommendation is to visit a site like Foxite.com to post the problem and get help from lots of smart VFP developers.
Okay. Thanks Rick. I'll give a shot at splitting the cursor. (It's just not gonna be easy though:-)
Rgds,
Suganya
Hi Rick.
Are there any FoxPro versions that allow a table larger than 2gb? We are currently using version 6.
Thanks!
No, the 2GB limit is what it is in all versions of Visual FoxPro and FoxPro. Advantage Database Server does manage to open DBFs larger than 2GB and there is always the ability for VFP to use remote data (MySQL, SQL Server, PostgreSQL, etc.)
Post a Comment
<< Home