The information in this article applies to:
SUMMARYRecompiling a Visual Basic Project that uses Binary Compatibility can generate a warning to the following effect: The dialog box offers a choice to either accept and break the compatibility or edit and preserve the return types or arguments. Alternatively, you may see the following error: These errors occur because the component, now being compiled with a later version of ActiveX Data Objects (ADO), is exposing objects such as a Recordset and is attempting to maintain Binary Compatibility with the component compiled with an earlier version of ADO. MORE INFORMATION
Visual Basic code makes use of Version Independent ProgIDs such as
"ADODB.Recordset". This Version Independent ProgID is then used to obtain a
Class ID for that particular class when you compile the project. Under ADO
1.5, for example, the Version Independent ProgIDs mapped to the ADO 1.5 Interface ClsIDs.
When you attempt to recompile a component with a later version of ADO, the Version Independent
ProgIDs now map to the later Interface ClsIDs. For example, ADO and later Interfaces are
not Binary Compatible with the ADO 1.5 interfaces.
to a version specific declaration:
There is a previous version specific ProgID exposed for each of the main
ADO objects, Recordset, Command, and Connection. To specify a version specific declaration, append the version identifier to the ADO object:
Note: Under ADO 2.0, objects were prefaced with an underscore, postfixed
with a version identifier and enclosed in square brackets.
After modifying the declarations, the project compiles without the Binary Compatibility warning. Following is a more complete example of taking the ADO code to a later version of ADO while maintaining binary compatibility with the earlier version. The following example is an ADO method that returns an ADO RecordSet object. If this function was compiled under ADO 1.5, you would have to modify the function declaration so that it would maintain binary compatibility with ADO 1.5.
Here is the same function modified so that when compiled with a later version of ADO, it
maintains binary compatibility with ADO 1.5:
The component or application that you compile against the later version of ADO requires the
later components to run successfully even if your component or
application only exposes the earlier interfaces. This is common practice when
compiling with dependencies. If you recompile a component with a newer
version of a dependency, the newer dependency becomes a baseline for the
resulting component and you need to redistribute the newer dependency file
with the component. This is no different than recompiling a Visual Basic
application under a newer version of Visual Basic. The resulting
application will not run if you do not distribute the new Visual Basic run-
time .dll with the application.
The benefit of this implementation in Visual Basic is that the code can take advantage of the new features and benefits of a new version of ADO and still remain binary compatible with clients expecting the earlier interfaces. © Microsoft Corporation 1999, All Rights Reserved. REFERENCESFor additional information on maintaining binary compatibility with an earlier version of ADO, click the article number below to view the article in the Microsoft Knowledge Base: Q222145 PRB: ADO Data Control Events May Generate a Compilation ErrorFor more information on binary compatibility, ProgID's and ClsID's, and COM please refer to the following books: Inside COM (Programming Series), Dale Rogerson, Microsoft Press, February 1997. Inside Distributed COM, Guy Eddon, Henry Eddon, Microsoft Press, April 1998. Understanding ActiveX and OLE, David Chappell, Microsoft Press, September 1996. STATUSThis behavior is by design. Additional query words:
Keywords : kbADO150 kbADO200 kbCompiler kbDatabase kbVBp500 kbVBp600 kbGrpVBDB kbGrpMDAC kbDSupport kbCmt kbADO210sp2 |
Last Reviewed: November 16, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |