> Have you tried my SetMemory program? It allocates memory based on > actual available physical RAM, and not the VM that Windows reports. > You may have to tweak it to optimize it for Citrix, but it should > give you a good start. It's available at http://leafe.com/dls/vfp.
I have some Data Translation routines that are quite demanding of both CPU and disk resources. With VFP 7 I would get an Out Of Memory error every once in a while (2000 Pro SP4, 1Gb DDR RAM), after chewing up a lot of translated bytes. I had plenty of RAM, lots of disk for VM, and opened up the maximum swap space I could within Windows. Ed showed me his SetMemory app, and I used it without any tweaking. The lack of RAM problem went away immediately. Now, after every translation session I run his app to reset the RAM utilization, then move on to the next translation. The only problem I had since then had nothing to do with RAM, but it was strange enough that I am going to share it in this eMail... A few months ago I compiled my TranslationEngine.exe app after doing some more tweaking to it (never ending saga, continual enhancements...). It ran perfectly on my development PC, but on my production machine every once in a while I would get an error advising there was "not enough space on c:\Documents And Settings\administr~1.NFDR~1\local\temp\xaVMSConversion.fxp". Not having time to chase down that little problem I wimply began to check on the TranslationEngine process each morning, and killed it after it completed its automation sequences (instead of letting it perpetually loop as it sought more translation work to do). But, with an upcoming trip to SoCal I thought I better look into it. Long story shortened... On the development PC I have a path named "c:\Documents And Settings\administrator.NFDR\local\temp" (notice the ".NFDR" after administrator). I have no such path on either the development or production PC (but they both have "c:\Documents And Settings\administrator\local\temp". I looked into Options|Paths, and for Temp files I found the problem. The "now invalid" path was in there, as opposed to a valid path. I reset the path to a valid value, set as default, recompiled the .exe and placed it on the production PC. All is fine now. Longer part of the story... So, what happened? Months ago I had a problem with my Domain Server, and had been logging onto the development PC as a User on the Local Machine. Apparently that was when I had just installed VFP 9 on the development PC, and about the time I had previously compiled my TranslationEngine application in VFP 9. Once I got my Domain Server back on line I began to log onto the development PC as a User on the Domain, as I had for years. But the development PC's hard drive failed shortly thereafter (coincidence, it comes in trhees). I restored the Drive C onto a new HDD using an image from the most recent automated Ghost imaging session, but that did not have VFP 9 on it. So I reinstalled VFP 9, copied my latest VFP 9 apps onto the new Drive C from the daily disk-to-disk backups, and everything looked great. The new Drive C did not have the "administrator.NFDR" path in it, since I did the reinstallation of VFP 9 as administrator logged onto the trusted domain! So, it was not hard to troubleshoot. But it did take me a while to go through what could have caused the problem to start with. Now this begs a question in my mind... If I build an .exe and use InstallShield to install it on a client PC, does the path for temp files from my development PC adjust in case the new client PC does not have the same path for temp files as I have on my developement PC? I have not tested it out yet, but wonder if anyone else has come across this errant behavior. Seems to me if a path is to be used for temp files, rather than crash if it does not exist the path ought to be built, or an alternate path found to use. Oh, this is the World of Windows, where such things are silly and non-sensical... Ciao! Gil > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Ed Leafe > Sent: Wednesday, August 09, 2006 4:37 PM > To: [EMAIL PROTECTED] > Subject: Re: sys(3050) and Citrix > > > On Aug 9, 2006, at 4:30 PM, Mike yearwood wrote: > > > SYS(3050) "allocates" foreground and background memory buffers. If I > > have a Citrix server - as each Citrix user starts a Fox app, Fox > > allocates more memory than it should. > > > > How can I demonstrate that too much memory is being allocated? > > Have you tried my SetMemory program? It allocates memory based on > actual available physical RAM, and not the VM that Windows reports. > You may have to tweak it to optimize it for Citrix, but it should > give you a good start. It's available at http://leafe.com/dls/vfp. > > -- Ed Leafe > -- http://leafe.com > -- http://dabodev.com > > > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** 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.
