BUG: ProgID and VersionIndependentProgID Switched for ADO 1.0ID: Q172550 |
The information in this article applies to:
- ActiveX Data Objects (ADO), versions 1.0, 1.5
SYMPTOMS
If 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.
CAUSE
The values for the ProgID and VersionIndependentProgID values in the CLSID for each ADO object were reversed. For example, for the CLSID of the ADO 1.0 Command object, located in the registry at the following the value of ProgID should be ADODB.Command.1, however, instead it is ADODB.Command:
HKEY_CLASSES_ROOT\CLSID\0000022C-0000-0010-8000-00AA006D2EA4
The value of VersionIndependentProgID should be ADODB.Command but it is ADODB.Command.1.
RESOLUTION
For ADO version 1.0, if you want the ProgID, use the VersionIndependentProgID, and vice-versa for the VersionIndependentProgID.
STATUS
Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article.
MORE INFORMATION
Typically, 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.
Additional query words: kbdse kbDatabase kbADO100bug kbADO110bug kbADO150fix
Keywords : kbADO Version : WINDOWS:1.0,1.5 Platform : WINDOWS Issue type : kbbug
Last Reviewed: February 14, 1999
