Yupp, and FYI controlling WorkingSet is also needed when automating IE (both from VB6 and vfp) for a longer stretch of time, as IE will just gobble up process space. Discovered it long ago, plus a quick dirty check for windowed instances like IE:
if you minimize the window (manual or programmatic - makes no difference) the WorkingSet will be trimmed, similar to vfp's wait window calling a doevents, so you can test in GUI if you see something weird in processes on tasklist...

>Interesting approach - thanks for sharing!
>
>>Yes I use the SYS(3050) function to control the memory. I found that when I upgraded my server from Windows Server 2012 to Windows 2016 my VFP Scheduled Tasks began to fail with not enough memory errors even though the new server had double the memory. Once I modified my VFP code with SYS(3050) limiting the tasks to 100-200mb of memory the errors went away. I also discovered that if I set the limit over 512mb the errors would return intermittently.
>>
>>I also have VFP COM objects running under Windows Services and noticed that the memory use just kept increasing as if I had a memory leak. It turned out the VFP memory cache was the issue so I added the following code to purge the memory cache once a day. My services run flawlessly and the memory stays consistent.
>>
>>Simon
>>
>>
>>

>>            Declare Integer SetProcessWorkingSetSize In kernel32 As SetProcessWorkingSetSize  ;
>>                    Integer hProcess , ;
>>                    Integer dwMinimumWorkingSetSize , ;
>>                    Integer dwMaximumWorkingSetSize
>>            Declare Integer GetCurrentProcess In kernel32 As GetCurrentProcess
>>            If SetProcessWorkingSetSize(GetCurrentProcess(),-1,-1)=0
>>               DECLARE INTEGER GetLastError IN kernel32
>>               This.WriteToLog("SetProcessWorkingSetSize() failed with "+Transform(GetLastError()))
>>               Clear Dlls "GetLastError"
>>            EndIf
>>            Clear Dlls "SetProcessWorkingSetSize","GetCurrentProcess"
>>
>>

>>
>>
>>>I think it's SYS( 3050 ) for the memory settings. From what I gather it's rarely necessary to set the values over 512MB and it can often be lower. I think that agrees with Simon's experiences.
>>>
>>>You also have to ask if anything else such as SQL Server will need to run on the Citrix server itself. Yes, it would be only one instance running as a service (not one instance per user) but it might need a chunk of RAM for itself, especially if it's serving 20 simultaneous users.
>>>
>>>>Hi Simon,
>>>>Thank you very much for your input. Since I already told the Citrix engineer that the app will need 2 gig, I won't go back and tell them otherwise. But I will look into what you describe as "VFP functions to define the maximum foreground and background ram" and learn how to do it.
>>>>
>>>>>Hi
>>>>>
>>>>>I use Terminal Services all the time and I have never had a VFP application use 2gig of ram. Under Windows Server 2016 I find that once you reach ~ 700 meg of ram the application will report there is not enough ram even if there is lots available. So I simply use the VFP functions to define the maximum foreground and background ram and I have had no troubles since. I often have 20-30 users running VFP applications on servers with 8-16 gig of ram depending on the server. The servers all use SDD/NVMe drives which helps a lot with performance.
>>>>>
>>>>>Simon
>>>>>
>>>>>>Me again :)
>>>>>>
>>>>>>I have confirmed from the Citrix engineer that (as Dragan correctly wrote) each user of my application will have a separate memory space (hence each user will have a user ID and password). And I wrote to the Citrix engineer that my app needs a minimum of 2 GB of RAM (just a guess on my part :)).
>>>>>>But now I am thinking. If 20 users log into the Citrix server to use my app and each is allocated 2 GB or RAM, would they (Citrix engineers) need to have the server with a minimum of 40 GB of RAM?