>I am not sure if this is entirely a Fox Pro issue, but I am hoping that someone can point me in the right direction. Some time ago I had a VFP 6.0 app run out of room on a Novell server and the data got corrupted. Since there were other applications on the server and the server was getting old and lacked resources, I moved the application to one of the user's PC and let the 2 users just share the application. Both users have 64 MB of RAM. From time to time their machines would lock up on them, sometimes in the Fox Pro app, sometimes in other software programs. Some of the tables in the FP6 app are larger (1 is 4MB, 1 is 2MB). As time goes on - or maybe they are just using the system more, they have more and more times when their machines lock up, - sometimes losing data. All of the forms in the app run as private data sessions. What seems to happen, however, is after they run 2 or 3 things from the menu, (ie a form which runs a report, a form which updates data, a form which runs
>a report, etc) their PC locks up and they have to reboot. Since each item is running as a private data session, the tables should not be staying open, and they often just run one item at a time.... you get the picture. In an attempt to solve this, I moved the application to a different server - thinking that it might be a particular machine issue - but it still seems to happen. I do think it is somewhat machine specific because when I run the app on my machine (I have 128 MB memory), I don't seem to have the problem.
>
>Is there something in my app I can do to help this ?
>
It sounds like you've got some confusion over RAM, memory and disk space, and have moved from a relatively stable fileserver environm,ent to peer-to-peer networking, which tends to make the overall system more subject to error. Let's deal with the memory and disk issues first.
Memory generally refers to the RAM on the system - VFP likes to use as much of it as possible. It not only considers physical memory, but also available virtual memory - disk space in the swap file - when it tries to allocate memory both for internal usage and for buffering of data.
VFP has a bad habit, especially under NT, of overallocating RAM resources; at times it tries to allocate more memory than is physically present in the system for its buffer space. There is a system parameter set with the SYS(3050) function that controls this allocation. I've found it to be advantageous to set the value to somewhat less than 1/2 the available physical RAM in the system, so that VFP doesn't thrash out - spending more time moving stuff between real memory and virtual memory than it would just doing normal disk I/O. This also alleviates some out of memory errors that can result from rapid expansion of the swap file when the swap file is on the same drive as VFP uses for temporary files.
Disk space is another, separate issue. VFP uses disk space for temporary buffering and intermediate file operations. You need to tell VFP where to put its temporary files - usually on a local drive that has plenty of free space is best. This is done with the TMFILES setting in CONFIG.FPW. VFP if left to its own devices arbitrarily picks the starting directory for the application to use as its temporary file space, and often this is not an optimal location.
Putting shared resources on peer machines is not a good strategy in most cases. For one thing, the performance of the local foreground application will suffer when significant I/O is being done on the network, and the network clients will get starved for service when the foreground task ties up the system resources. In addition, you risk all the data for all stations when the shared system is locked up or shut down; the peer-to-peer environment is less stable and less capable than most environments with dedicated file servers. YMMV - this is based on a wide body of literature in the industry, and my own experiences supporting VFP applications in network environments for a long time.
