Article ID: 177912 - View products that this article applies to.
This article was previously published under Q177912
This article has been archived. It is offered "as is" and will no longer be updated.
When calling COleVariant::Clear(), an access violation occurs when the variant type is VT_DECIMAL.
There is special code in COleVariant::Clear() that checks the type of the variant and calls SysFreeString() if it is equal to VT_BSTRT (14). Here is the code:
VT_BSTRT is used to identify ANSI BSTRs and is a special type that MFC uses internally. The problem is that OLE also defines VT_DECIMAL to be 14.
Thus, if you call Clear() on a COleVariant, which has a variant type of VT_DECIMAL, an access violation will occur because the function calls SysFreeString() on a non-existent string.
Don't call COleVariant::Clear(); instead, call VariantClear() and pass in the COleVariant.
Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. This problem was corrected in Visual C++ version 6.0 for Windows.
The GetRows() ADO sample, which is provided with the OLE DB 1.1 SDK, contains code that can cause the access violation when calling Clear().
Here is the DoGetRows() function from GETRDLG.CPP:
NOTE: If the column type returned from the ADO source is VT_DECIMAL, the varField.Clear() function will crash because COleVariant::Clear() calls SysFreeString() on data that is not a string.
To reproduce the error, add the following lines of code to the function CGetRowsDlg::DoGetRows():
Add the code just before the line:
Article ID: 177912 - Last Review: October 7, 2013 - Revision: 1.0