FIX: Deleting CRecordset Object Before Closing It

 Last reviewed: September 18, 1997
Article ID: Q113815
1.50 1.51 WINDOWS kbprg kbfixlist kbbuglist

The information in this article applies to:

  • The Microsoft Foundation Classes (MFC), included with: Microsoft Visual C++ for Windows, versions 1.5 and 1.51

SYMPTOMS

If a CDatabase object is allocated and then passed into a CRecordset constructor the user may notice a memory leak if the CRecordset is 

deleted before calling CRecordset::Close().   Not only will memory
leak, but the following ODBC error may eventually occur when using snapshots (or more specifically, when using the cursor library): 

    General Error: Unable to create file buffer
    State:S1000

CAUSE

A bug in the CRecordset destructor prevents the ::SQLFreeStmt() from getting called for the ODBC statement handle (HSTMT) used by the CRecordset object.

RESOLUTION

To work around the problem, make sure that CRecordset::Close() is called before it is deleted. One way to handle this is to put a call to CRecordset::Close() in the destructor of the CRecordset-derived class.

STATUS

Microsoft has confirmed this to be a bug in the products listed at the beginning of this article. This bug was corrected in MFC version 3.0, included with Visual C++, 32-bit Edition, version 2.0.

MORE INFORMATION

The CRecordset destructor has the following code: 

    CRecordset::~CRecordset()
    {
        if (!m_bRecordsetDb)
            m_pDatabase = NULL;

        ASSERT_VALID(this);

        TRY
        {
            Close();
            if (m_bRecordsetDb)
            {
                delete m_pDatabase;
                m_pDatabase = NULL;
            }
        }
        ...
The m_bRecordsetDb is a flag that the CRecordset class uses to tell whether the CRecordset created the CDatabase object or whether it was passed to the CRecordset in the constructor. If a program passes in the CDatabase pointer to the CRecordset, looking at the code you can see that m_pDatabase will be set to NULL. Unfortunately this causes a problem when Close() is called later in the function. In CRecordset::Close() the following lines determine whether the HSTMT allocated by the CRecordset needs to be freed: 

   if (m_pDatabase != SQL_NULL_HDBC)
      {
          AFX_SQL_SYNC(::SQLFreeStmt(m_hstmtUpdate, SQL_DROP));
      }
Since m_pDatabase has been set to NULL and the CDatabase object still exists, we run into a problem because SQL_NULL_HDBC is equal to NULL. Thus, the statement handle is never freed although the CRecordset goes away. This normally isn't too much of a problem because statement handles get freed when a connection goes away. However, if you are re-using a CDatabase for multiple CRecordset objects, many allocated HSTMTs will accumulate.

Additional reference words: 1.50 2.50 2.51 odbc
KBCategory: kbprg kbfixlist kbbuglist
KBSubcategory: MfcDatabase
Keywords : kb16bitonly MfcDatabase kbbuglist kbfixlist kbprg
Technology : kbMfc
Version : 1.50 1.51
Platform : WINDOWS
Solution Type : kbfix

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: September 18, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.