Hi Guys.

I don't suppose that you could change the registry setting for VFP's temp files and then issue a Sys(2056) to get it to read the new setting? A Sys(2056) is supposed to make it read all the File Location tab settings. You'd have to make sure that there is no TMPFiles setting in your Config.FPW though as that will override the registry.

Actually, even if for some reason that didn't work, what about putting code in to rewrite the registry entry so that the next copy of VFP to start will be in a different directory? You'd have to be clever about how you clean these generated temporary directories up, and I'm sure that occasionally two copies will start at once so they'll still wind up in the same directory. None the less, it should greatly cut down the number of times that you do wind up with multiple servers in the same directory.

Ian Simcock.



>Well, it's COM instantiation, so the server gets instantiated externally and there's not a lot that can be done about that from that end.
>
>I had played around with changing the user the VFP app runs under AFTER it's been launched in hopes VFP would pick up the temp folder change, but VFP doesn't do that. VFP loads the original environment and then caches it so even changing the applications' internal environment (which is affected by a user change) doesn't change the temp path.
>
>This is a huge bummer actually, but the amount of traffic John's dealing with is truly massive.
>
>The better solution IMHO is to scale out and reduce the number of simultaneously executing instances as much as possible. It might even be enough to reduce the number of simultaneous instances executing to a smaller number and going for longer response times and queing (assuming request times are fairly quick). Fewer instances should translate in lower conflict possibilities.
>
>+++ Rick ---
>
>
>>>Al, it's a good idea but it looks as if the VFP exe gets run as a separate process, iow not part of the COM instance.
>>>
>>>I have to laugh... in the past I've emphasized VFP's automatic dataset spooling to disk as an amazing advantage and now it's come back and bitten me on the proverbial. ;-) If JVP were here, finally he could quote a scaling limitation of VFP to which there is no easy answer. ;-)
>>>
>>>IMHO probably it would be quite easy for MS to create a new config.fpw setting to automatically create a unique temp folder location for each instance. Shame this didn't happen a bit earlier, right? ;-)
>>
>>If you can't control instanciation, that limits your options.
>>
>>One other way-out-in-left-field possibility is using RunAs or equivalent to load instances under different user accounts. Each account has a separate temp folder, this would work around the issue. I know very little about the architecture of WC apps, I don't know if this would be possible.