Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
Memory Use Climbs with Multiple Recordsets Under a Single Jet Session/Connection
Article ID: 247140 - View products that this article applies to.
This article was previously published under Q247140
Setup for Microsoft Data Access Components (MDAC) 2.1 or later installs a new major version of the Microsoft Access ODBC driver. This new Access ODBC driver uses the Microsoft Jet 4.0 database engine, which enables access to Microsoft Access 2000-format databases as well as all previous Access database formats. The Microsoft Access ODBC driver that was included with MDAC 1.5 and 2.0 uses the Microsoft Jet 3.5 database engine to manipulate the Microsoft Access database file.
Because of design changes in Jet 4.0 as well as backward compatibility issues in the new ODBC driver, installation of the updated Access ODBC driver can break existing, installed ODBC applications that use the Access ODBC driver, which may force the developer to recode the application in some cases.
Microsoft Jet 4.0 is not releasing cached resources until the parent database connection is closed. Note that this is not a memory leak; rather, this is a resource allocation that is never freed until the parent object is closed.
To resolve this problem, install the latest Microsoft Jet 4.0 service pack. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/239114/ )How To: Obtain the Latest Service Pack for the Microsoft Jet 4.0 Database Engine
One workaround is to periodically close and then re-open the parent connection to release the memory used.
Another workaround is to apply the hotfix described in this Microsoft Knowledge Base article.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was fixed in Jet 4.0 Service Pack 6 (SP6).
In general, this issue occurs when you open and close multiple recordsets under a single database connection in conjunction with manipulating each recordset in some fashion. For example, if you add or delete some records from each recordset that is opened and closed, the leak may occur. The issue can also occur if you use a parameterized SQL statement. If you just open each recordset and read some records for example, the leak does not occur. The leak is small so you must monitor the private bytes used by the process for a long time to determine whether or not the leak applies to a specific case.
Article ID: 247140 - Last Review: September 26, 2005 - Revision: 3.2