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.