FIX: Storing an ADO Recordset in GIT Might Cause An Access Violation

Article translations Article translations
Article ID: 249175
This article has been archived. It is offered "as is" and will no longer be updated.
Expand all | Collapse all

On This Page


The following paragraph is taken from the Microsoft Knowledge Base article 248287, "Understanding ADO Marshaling", which describes the potential problem of using the COM Global Interface Table with ActiveX Data Objects (ADO) Recordsets.

"COM provides a component called the Global Interface Table (GIT). The GIT allows an application to store a reference to an object's interface in the table so that the interface pointer can be retrieved at any time. When storing the interface pointer into the GIT, the object is queried for IMarshal and if IMarshal is exposed by the object, the marshaling data of the object is placed into a stream where it can be retrieved at some later time when the interface pointer is retrieved. IMarshal is exposed by the client cursor which actually does the passing of the recordset data. There is a problem if an open ADO Recordset object which uses adUseClient is placed into the GIT and then is later revoked from the table. An access violation will occur. To avoid the problem, place the Recordset's interface pointer into the GIT before calling Open on the Recordset. This will place the interface pointer into the GIT before the client cursor engine is invoked which will essentially cause standard marshaling to occur rather than record data being streamed from the cursor engine through IMarshal. Only a pointer to the ADO Recordset's interface will be stored in this case which is the real intent of the programmer."


To avoid an access violation in your code you can either apply the hotfix listed in this article, or you can use one of the following workarounds:
  • Do not use a client-side cursor.


  • Store the recordset into GIT before you open the recordset.
NOTE: Because ADO disconnected recordsets require a client-side cursor, you cannot use the first workaround. However, the second workaround works if you are using ADO Recordset.Open() to open the recordset, but it will not work for the Connection.Execute() or Connection.OpenSchema() methods if the returned recordset is already open. In that case, the workaround is somewhat tricky.

If a call to an ADO method returns a recordset that is already open, you can use the following steps to work around the problem:

  1. Persist the recordset object into a file or IPersistStream memory object. To persist an ADO recordset into a file, use the Recordset.Save() method. To persist an ADO recordset to IPersistStream, see the following article in the Microsoft Knowledge Base:
    242249 Saving an ADO Recordset to an IStream
  2. Instantiate a new ADO Recordset object.
  3. Store the new recordset in GIT by using the RegisterInterfaceInGlobal() method.
  4. Load the new recordset object from the persisted data in step 1.


Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.

This problem was corrected in MDAC 2.6.
A supported hotfix is now available from Microsoft, but it is only intended to correct the problem that is described in this article. Only apply it to systems that are experiencing this specific problem. This hotfix may receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next Microsoft Data Access Components release that contains this hotfix.

To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information about support costs, visit the following Microsoft Web site:
NOTE: In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The typical support costs will apply to additional support questions and issues that do not qualify for the specific update in question.

The English version of this fix should have the following file attributes or later:
   Date         Time    Version       Size      File Name     Platform

   05/04/2000   19:32   2.51.5303.1   327,952   Msadce.dll    x86 
   05/03/2000   19:31   2.51.5303.0   487,696   Msado15.dll   x86 

More information

Steps to Reproduce Behavior

  1. Create a new project in Microsoft Visual C++ and add the following code to the project:

    #import "C:\Program Files\Common Files\System\ado\msado15.dll" no_namespace
    //you may need to add proper code to make this complete
    //Open a Connection
    hr = pConn->Open("DSN=Datasource1", "UserID1", "PWD1", -1);
    if (SUCCEEDED(hr)) 
    	//Use client side cursor
    	// Now Open an ADO Recordset
    	pRecordSet = pConn->Execute("jobs", &recs, -1);
    	// Store the recordset in GIT 
    	hr =  gGlobalIntTable->RegisterInterfaceInGlobal(pRecordSet, IID_IDispatch, &cookie);
    	// Now revoke from GIT (to see the crash!)
    	if (hr == S_OK)
    		hr = gGlobalIntTable->RevokeInterfaceFromGlobal(cookie); //Crash!!!
    	// Close the ADO Recordset 
  2. If you run the above code, you get a fatal error in the RevokeInterfaceFromGlobal() call. The following code fixes that problem:
    	// Open a Connection
    	hr = pConn->Open("DSN=Datasource1", "UserID1", "PWD1", -1);
    	if (SUCCEEDED(hr)) 
    		// Now Open an ADO Recordset
    		pRecordSet = pConn->Execute("jobs", &recs, -1);
    		//Save this Recordset in a file
    		hr= pRecordSet->Save("c:\\mytemp.tmp",adPersistADTG);
                      //Close the ADO Recordset we don't use this anymore
    		//Now Create a new recordset
    		_RecordsetPtr pRECORDSET2(__uuidof(Recordset));
    		// Store the SECOND recordset in GIT 
    		hr =  gGlobalIntTable->RegisterInterfaceInGlobal(pRECORDSET2, IID_IDispatch, &cookie);
    		// Load the SECOND recordset from the persisted 
    		hr =  pRECORDSET2->Open("c:\\mytemp.tmp", vtMissing, adOpenStatic, adLockUnspecified, -1);
    		// Now revoke from GIT
    		if (hr == S_OK)
    			hr = gGlobalIntTable->RevokeInterfaceFromGlobal(cookie); 

    Note that the second recordset that was created without using client-side cursor works fine.


  • CLSID_StdGlobalInterfaceTable
  • Global Interface Table
  • Unhandled Exception
  • R6025
  • Pure Virtual Function Call


Article ID: 249175 - Last Review: June 19, 2014 - Revision: 4.0
kbnosurvey kbarchive kbqfe kbhotfixserver kbado260fix kbbug kbfix kbmdacnosweep kbwin2000sp1fix KB249175

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from