BUG: ProgID & VersionIndependentProgID Switched for ADO 1.0Last reviewed: August 11, 1997Article ID: Q172550 |
The information in this article applies to:
SYMPTOMSIf you explicitly specify values for the CLSID of ADO 1.0 objects, requesting either the ProgID or VersionIndependentProgID values in the registry, these values do not have the expected effect. ProgIDFromCLSID returns the version independent ProgID instead of the dependent ProgID because of this bug.
CAUSEThe values for the ProgID and VersionIndependentProgID values in the CLSID for each ADO object were reversed. For example, for the CLSID for the ADO 1.0 Command object, located in the registry at the following the value of ProgID should be ADODB.Command.1--instead it is ADODB.Command:
HKEY_CLASSES_ROOT\CLSID\0000022C-0000-0010-8000-00AA006D2EA4The value of VersionIndependentProgID should be ADODB.Command--instead it is ADODB.Command.1.
RESOLUTIONFor ADO version 1.0, if you want the ProgID, use the VersionIndependentProgID, and vice-versa for the VersionIndependentProgID.
STATUSMicrosoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this bug and will post new information here in the Microsoft Knowledge Base as it becomes available.
MORE INFORMATIONTypically, users come at the CLSID of an object via the PROGID. This includes Visual Basic's CreateObject, so this problem does not cause a problem for Visual Basic users. The only time this bug would create a problem is if you have ADO version 1.0 and a later version on the same machine. If you just have 1.0 installed, then it is a moot point since the dependent and independent ProgID's point to the same clsid.
Keywords : adoall Version : WINDOWS:1.0,1.5 Platform : WINDOWS Issue type : kbbug |
================================================================================
© 1998 Microsoft Corporation. All rights reserved. Terms of Use. |