ADO memory leak when getting Recordset from an Oracle stored procedure?

Question

I am programming in C++ (VC 6) and using ADO 2.7 to
access Oracle 9i database. My connection string looks
like this:
Provider=MSDAORA.1;Persist Security Info=True;User ID=scott;Password=tiger;Data Source=blahblah
I have Oracle stored procedure that returns data in a
REF CURSOR output parameter. Since the stored procedure
takes input parameters, I prepare a Command object with
Parameters initialized and attached to it. I use the
Recordset Open method to execute the call. This approach
works because I get correct data back from the call in
the Recordset, but the problem is when I do this in a
infinite loop and watch the process in Windows Taks
Manager, I see 4k or 8k memory delta all the time and
the Peak Memory Usage of the process keeping going up.
I hope someone knows something in this scenario and points
me to the right direction.
Thanks, please see the following code for specifics.
HRESULT CallSP3Params(VARIANT vp1, VARIANT vp2, int spretcode, LPDISPATCH ppRSet, char *pCmdLine)
     _RecordsetPtr     pRs;
     _CommandPtr     pCmd;
     _ParameterPtr     paramVProfiler[3];
     bstrt          strMissing(L"");
     *ppRSet = NULL;
     variantt          ErrConn;
     ErrConn.vt = VT_ERROR;
     ErrConn.scode = DISP_E_PARAMNOTFOUND;
     try {
     //Create instance of command object
     pCmd.CreateInstance(__uuidof(Command));
     pRs.CreateInstance(__uuidof(Recordset));
          if ( vp1.vt == VT_BSTR ) {
               paramVProfiler[0] = pCmd->CreateParameter("P1",adVarChar,adParamInput,SysStringLen(vp1.bstrVal) + 10,strMissing );
               paramVProfiler[0]->Value = vp1;
          else if ( vp1.vt == VT_I4 )
               paramVProfiler[0] = pCmd->CreateParameter("P1",adNumeric,adParamInput,15,vp1);
          else
               TESTHR( PARAMETER_OPERATION_ERROR );
          pCmd->Parameters->Append(paramVProfiler[0]);
          if ( vp2.vt == VT_BSTR ) {
               paramVProfiler[1] = pCmd->CreateParameter("P2",adVarChar,adParamInput,SysStringLen(vp2.bstrVal) + 10,strMissing );
               paramVProfiler[1]->Value = vp2;
          else if ( vp2.vt == VT_I4 )
               paramVProfiler[1] = pCmd->CreateParameter("P2",adNumeric,adParamInput,15,vp2);
          else
               TESTHR( PARAMETER_OPERATION_ERROR );
          pCmd->Parameters->Append(paramVProfiler[1]);
          paramVProfiler[2] = pCmd->CreateParameter("RETCODE",adNumeric,adParamOutput,10);
          pCmd->Parameters->Append(paramVProfiler[2]);
     //Catch COM errors
     catch( comerror &e) {
     try {
     // I manage my connection through this little C++ class of my own
     CCUsage myconnection( &Connectionkeeper[0] );
     //Set the active connection property of command object to open connection
     pCmd->ActiveConnection = myconnection.m_conn;
     //The command type is text
     pCmd->CommandType = adCmdText;
     //Set command text to call the stored procedure
     pCmd->CommandText = pCmdLine;
     //Open the Recordset to get result
     pRs->Open( variantt((IDispatch *)pCmd,true), ErrConn, adOpenStatic, adLockReadOnly, adOptionUnspecified );
     //Disconnect the command object
     pCmd->PutRefActiveConnection( NULL );
     if ( GetSPRetCode( pCmd, "RETCODE", spretcode ) != S_OK )
          TESTHR(DB_OBJECT_OPERATION_ERROR);
     // pRs->QueryInterface(IID_IDispatch, (void**) ppRSet);
     // I return the Recordset by calling QueryInterface, but even without that, closing the Recordset right here still shows memory leak.
     pRs->Close( );
     pRs = NULL;
     //Catch COM errors
catch (_com_error e) {
     return S_OK;
}

Answer 1

Whenever large numbers of BSTRs are allocated and freed quickly the process memory will continue to climb towards a stabalizing value. BSTRs are not freed until the system frees them. You can see this by making many calls allocating and freeing BSTRs, memory will climb, but when you stop for a while the gargage collection of the sys strings will take place. I've done much research to see that a server doing many queries very rapidly is not leaking memory, but out pacing the garbage collection, it will stabilize and when the process has some "rest time" the processes memory usage will decline.
In my research a suspected memory leak was not one.