BUG: ProgID and VersionIndependentProgID Switched for ADO 1.0

ID: 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