BUG: Storing an ADO Recordset in GIT May Cause Access Violation

ID: Q249175

The information in this article applies to:

ActiveX Data Objects (ADO), versions 2.1, 2.5

SYMPTOMS

The following paragraph is taken from Knowledge Base article Q248287 Understanding ADO Marshaling, which describes the potential problem of using the COM Global Interface Table with 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."

RESOLUTION

To avoid an access violation in your code do the following:

Either don't use client-side cursor.

Or store the recordset into GIT before you open it.

NOTE: Since ADO disconnected recordsets requires client-side cursor, you can't use "a" as a workaround. Although "b" does work if you are using ADO Recordset.Open() to open the recordset, it won't work for Connection.Execute() and Connection.OpenSchema() methods where the returned recordset is already opened. In this case the workaround is somewhat tricky.

If calling ADO methods returns an already opened recordset, the following steps may be taken to work around the problem:

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 to IPersistStream, see the following Knowledge Base article:

Q242249 Saving an ADO Recordset to an IStream.

Instantiate a new ADO Recordset object.

Store the new recordset in GIT using the RegisterInterfaceInGlobal() method.

Load the new recordset object from the persisted data in step one.

STATUS

Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article.

MORE INFORMATION

Steps to Reproduce Behavior

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

#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
	pConn->PutCursorLocation(adUseClient);

	// 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 
	pRecordSet->Close();
}

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
		pConn->PutCursorLocation(adUseClient);
		pRecordSet = pConn->Execute("jobs", &recs, -1);

		//Save this Recordset in a file
		remove("c:\\mytemp.tmp");<BR/>

		hr= pRecordSet->Save("c:\\mytemp.tmp",adPersistADTG);
                  //Close the ADO Recordset we don't use this anymore
		pRecordSet->Close();
		
		//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.

REFERENCES

CLSID_StdGlobalInterfaceTable

Global Interface Table

Unhandled Exception

R6025

Pure Virtual Function Call

Additional query words:

Keywords : kbADO kbGrpVCDB kbGrpMDAC kbDSupport kbADO250 kbADO250bug
Version : WINDOWS:2.1,2.5
Platform : WINDOWS
Issue type : kbbug