Hi!

Ouch!

MTS uses the marchalling for ADO, and seems you have found a great bug in that. Try to post this to the MS. MTS/COM+ is quite new technology that is growing a lot last time, so I guess they will be interested.

BTW, I have tried this on my machine and experienced the same. ADO 2.6 + VFP6 SP3 + MTS + Win NT 4.0 SP6. I also tried this with use of the MTS transactions. Still the same. Than, I have tried returning of the recordset from the object using full marshalling option, and returning it in a loop in the VFP called that object. It worked with memory leak too. I experimented with it a lot with no luck. Very strange and pity, this approach of record set returning is quite useful.

Anyway, MTS have an option to shutdown service automatically when certain time of inactivity, but this works only if all objects are not active (In other words, all objects used SetComplete or SetAbort). This way server will shutdown often in time when load is little.

Take a look also to the downloads section for my document that shows the speed of other approaches of passing data between COM objects (DCOM tests or something like that). Maybe you will be interested to use one of the approaches for data transfer instead of ADO. Contact me if you need a source code.

HTH.

>Yeah, the memory is released only once I close VFP. Isn't 2.6 the latest version of ADO?
>And, yes, I am using this inside a MTDLL running under MTS. I'm currently having to shut down the package every 12 hours or so. I've thought about automating that, but haven't bothered with it hoping that I'd get the problem resolved.
>BTW, this also occurs in VFP7 Beta 2 + Win2k Sp2 + MDAC 2.6.
>
>>Hi!
>>
>>Strange. Does memory leak goes away as soon as you close VFP?
>>In addition, did you tried to install the latest version of ADO?
>>Finally, if you require this for automation service, I would suggest to make a supporting (controlling) service, that restart the main service each night or more often. This way you will forget about any memory leak in the main service, just because application will be restart.
>>
>>HTH.
>>
>>>Sigh. Well, I was praying that it would work. I hadn't seen SYS(1104) before. But, alas, it didn't. Same results.
>>>I had already tried creating and releasing the recordset each time it loops, but moved it out to speed things up when I found that it didn't make a difference.
>>>I appreciate the suggestion though :)