Thanks for reporting the COM memory leak. I was the original finder of that one.
It took quite a few tech calls to get someone at MS to accept the bug. I am suprised that it is not fixed. I was just getting ready to test VFP6.0 with SP3 MTDLL changes. You just saved me a weeks worth of work!!!

I have come to the same conclusions as you have. Right now I have my web server's rebooting every night to compensate for the problems.

Thanks again!

>I have just downloaded VS SP3 and I must say that I am very impressed with the performance and apparent (so far) stability of the new MTDLL's. I was, like so many others, very disappointed with the problems in VFP6.0 COM. However, it seems that at least one problem has not been corrected, and I am hoping for some help in picking a strategy to deal with the problem...
>
>I am using a VFP6.0 COM DLL as an HTML generator in ASP. The problem is that as per Article ID: Q197206 in the MS Knowledge Base, there still seems to be a small memory leak. If I watch the NT Task Manager I can watch the memory usage if MTX grow. It drops back down during periods of inactivity, but each hit seems to cause the baseline reading during idle state to be 4k-8k larger than it was before the hit (as advertised). Eventually, after a certain amount of time this begins of course to degrade the performance of the Web Server and after a time causes serious errors. This is not acceptable. I had hoped that they would fix this problem in VFP6T, but apparently not.
>
>I can think of three strategies to deal with the problem. I'm not crazy about any of them except the first, should it prove doable:
>
>1. Stop using COM objects to generate HTML and instead use them as middle tier objects to get/set and post data. This was my intial approach with VFP6 COM and I have class libraries raring to go, but with the first release of VFP6 and method blocking this was a completely non-scalable approach. All the calls over COM were slow, especially for iterative processes, and a couple of concurrent users was all it took to kill it. Can I expect this to be better with SP3?
>
>2. Shut down the Web Server and restart and predefined intervals. Always an option, but doesn't look very good when you have to tell the client, "Well, the app will only run for a day or two before you have to restart it." I know I can autoschedule it but that doesn't help much in the case of failure - what if the Web Service won't stop (a common occurence).
>
>3. Write the resultant HTML to a file and then load it into the ASP Page from file instead of as a return value from a COM object. THis seems like an ugly way to go, although it probably will work, as per Rick Strahl I believe. Questions are: with MTDLL, how to guarantee a unique destination (will the simultaneous execution do anything to our old SYS() commands?) and how to load the resultant file (FileSystem Object?).
>
>I know I'm asking a lot of questions. I've saved them all up for a while waiting for SP3 to see how things would be. I can probably get some of these answers from Rick's new book, which I will get soon, but any insight anyone has in to any of the above solutions, or any others that I haven't thought of will be GREATLY appreciated.