Microsoft KB Archive/269842

= PRB: ADO Disconnected Recordset Appears to Leak Memory when Editing in Place =

Article ID: 269842

Article Last Modified on 5/12/2003

-

APPLIES TO


 * Microsoft Data Access Components 2.5
 * Microsoft Data Access Components 2.5 Service Pack 1
 * Microsoft Data Access Components 2.6
 * Microsoft Data Access Components 2.7

-



This article was previously published under Q269842



SYMPTOMS
When you attempt to update the same field repeatedly in an ActiveX Data Objects (ADO) disconnected Recordset, you may see memory increase as if there was a memory leak. This behavior only occurs with certain data types. Please see the &quot;More Information&quot; section of this article for a list of affected data types.



CAUSE
The ADO disconnected Recordset uses a memory-mapped file for storage. When you modify a field of certain types that are affected by this behavior, a new buffer is created at the end of the rowset and the new value is added there. Repeatedly modifying an existing record results in memory increasing continuously as the memory-mapped file gets larger and larger. The update algorithm does not recognize that it is just an in-place update.

Although this behavior appears to be a memory leak, it is not truly a leak because the memory gets reclaimed when the Recordset is released.



STATUS
This behavior is by design.



Steps to Reproduce Behavior
 Create an empty console application project in Microsoft Visual C++.  Insert the following sample code that updates one field of the same record repeatedly:
 * 1) undef EOF
 * 2) import &quot;C:\Program Files\Common Files\System\Ado\msado15.dll&quot; no_namespace

void main(void) {   _RecordsetPtr rs; HRESULT hr = CoInitialize(NULL);

try {       hr = rs.CreateInstance(__uuidof(Recordset)); rs->CursorLocation = adUseClient; rs->Fields->Append(&quot;BSTRString&quot;,adBSTR,10,adFldUpdatable); hr = rs->Open(vtMissing,vtMissing,adOpenStatic,adLockOptimistic,-1); hr = rs->AddNew; rs->Fields->GetItem(&quot;BSTRString&quot;)->Value = OLESTR(&quot;&quot;); //make the leak here //update the first record repeatedly _bstr_t bstrTest(&quot;Text to update field to.&quot;); rs->MoveFirst; for (int i = 0; i < 100000; i++) {           rs->Fields->GetItem(&quot;BSTRString&quot;)->Value = bstrTest; rs->Update; }       rs->Close; }   catch(_com_error& e) { _bstr_t bstrErrorMessage(e.ErrorMessage); _bstr_t bstrDescription(e.Description); }

}

 Compile and run the application. Watch this process with PerfMon, and you will notice a steady increase in the Private Bytes counter for the process, similar to what happens with a memory leak.

Affected Data Types
The following types of fields all are subject to this behavior:

To prevent the memory increase, use the preceding chart to choose a data type that is not affected by this behavior. For example, an adChar of size 255 or smaller. Closing the recordset frees the memory as well.

Keywords: kbfix kbcodesnippet kbprb KB269842

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.