Consultor Eletrônico



Kbase 19741: Troubleshooting Apparent MERANT ODBC Driver Memory Leaks
Autor   Progress Software Corporation - Progress
Acesso   Público
Publicação   21/08/2003
Status: Technically Reviewed

FACT(s) (Environment):

Troubleshooting Apparent ODBC Driver Memory Leaks.

FACT(s) (Environment):

Progress 8.x

FACT(s) (Environment):

Progress 9.x

FACT(s) (Environment):

MERANT ODBC driver 3.5

FACT(s) (Environment):

MERANT ODBC driver 3.6

FIX:

According to MERANT there are presently no known memory leak issues. Some reported leaks relate to very old copies of the Microsoft DLL odbc32.dll (1.0). These never related to MERANT ODBC products.

NOTE: The MERANT ODBC driver 3.5/3.6 requires ODBC 3.51 components.

A common cause of memory leaking behavior is the use of the
SQLFreeStatement with SQL_CLOSE instead of SQLFreeStmt SQL_DROP. If
used as such, the ODBC driver is instructed not to release any
resources because the statement handle can be reused.

About the 2.0 ODBC API function SQLFreeStmt:


        SQLFreeStmt stops processing associated with a specific                   hstmt, closes any open cursors associated with the hstmt,
        discards pending results, and, optionally, frees all
        resources associated with the statement handle.

        Syntax:  RETCODE SQLFreeStmt(hstmt, fOption)

       The SQLFreeStmt function accepts the following arguments:

       Type   Argument  Use        Description
       HSTMT  hstmt     Input      Statement handle

       UWORD  fOption   Input      One of the following options:

             --SQL_ CLOSE: Close the cursor associated with hstmt
               (if one is defined) and discard all pending results.
               The application can reopen this cursor later by
               executing a SELECT statement with the same or
               different parameter values. If no cursor is open, this
               option has no effect for the application.

             --SQL_DROP: Release the hstmt, free all resources
               associated with it, close the cursor (if one is open),
               and discard all pending rows. This option terminates
               all access to the hstmt. The hstmt must be reallocated
               to be reused.

             --SQL_UNBIND: Release all column buffers bound by
               SQLBindCol for the given hstmt.

             --SQL_RESET_PARAMS: Release all parameter buffers set by
               SQLBindParameter for the given hstmt.

NOTE: An application can call SQLFreeStmt to terminate processing of a
SELECT statement with or without canceling the statement handle.

To see if this is the case:
               Turn on the SQL Trace option. In the SQL Trace log you
               would find something like:

               MSQRY32         9c:b6       ENTER SQLAllocStmt
               HDBC                0x00c714e8
               HSTMT *             0x0003f2e0

               MSQRY32         9c:b6       EXIT  SQLAllocStmt with
                                                     return code 0
              (SQL_SUCCESS)
               HDBC                0x00c714e8
               HSTMT *             0x0003f2e0 ( 0x00c72860)

              With:
              MSQRY32         9c:b6        ENTER SQLFreeStmt
              HSTMT                0x00c72230
              UWORD                        0 <SQL_CLOSE>

              Or:
              MSQRY32         9c:b6        ENTER SQLFreeStmt
              HSTMT               0x00c72548
              UWORD                        1 <SQL_DROP>