BUG: Access 2000 Object Model breaks binary compatibility (246237)


The information in this article applies to:

  • Microsoft Access 2000
  • Microsoft Access 2002
  • Microsoft Office Access 2003
This article was previously published under Q246237

SYMPTOMS

Automation clients written for Microsoft Access 97 that use either early binding (VB, ATL with #import) or dispid binding (MFC) might unexpectedly fail when trying to automate Microsoft Access 2000,Microsoft Access 2002, or Microsoft Office Access 2003.

Among the possible errors you might receive as a result of this problem are:
0x80020003 : 438 - Object doesn't support this property or method.
0x80020004 : 448 - Named argument or parameter not found.
0x80020005 : 13 - Type mismatch.
Many functions might also produce custom errors from Access or might not return an error at all; that is, the call appears to have succeeded but the correct method was not called.

CAUSE

During development of Access 2000, the Access object model was accidentally modified in a way that breaks both binary (v-table) and dispid compatibility with Access 97. Any client application that uses early or dispid binding to Access 97 might fail to work properly when run against Access 2000,Access 2002, and Access 2003.

The following non-compatible changes were made to the Access Object Model:
  • Both the Report and Form objects have new properties and/or methods inserted in the middle of their respective interfaces. This means that the binary layout of each object's v-table have been changed, while the interface identifiers (IIDs) were left unchanged. This is a violation of the rules of COM and has resulted in a binary incompatibility with previous versions of Access.

    Clients using early binding to the Access 97 type library can expect calls made to these objects to fail in Access 2000/2002/2003 because the methods they intend to call have been mistakenly moved in newer versions of Access.

  • A number of properties and methods in the Access Object Model have had their dispatch identifiers (dispids) changed. As a result, any Automation client that stores dispids from the Access 97 type library and uses them in Access 2000 might receive errors when calling these methods.

    NOTE: MFC programmers are the most likely to see this problem. While you can use the Class Wizard-generated wrapper classes to automate a particular version of Access, they do not work for all versions.

  • All of the following controls have been changed to inherit from IAccessible instead of IDispatch: 
      BoundObjectFrame     CustomControl        OptionGroup
  CheckBox             Label                TabControl
  ComboBox             ListBox              TextBox
  CommandButton        OptionButton         ToggleButton
    This change resulted in additional methods being added to the beginning of the v-table for these objects. As noted above, clients using early binding to the Access 97 type library might accidentally call the wrong methods or properties when communicating with these objects in newer versions of Access.

RESOLUTION

Automation clients that want to Automate Access 97, Access 2000,Access 2002, and Access 2003 "must" use late binding (that is, IDispatch::GetIdsOfNames and IDispatch::Invoke).

STATUS

Microsoft has confirmed this to be a bug in Access 2000.

However, due to the number of clients currently using early binding to Access 2000, this problem cannot be fixed without risking further incompatibilities. Access 2002 remains compatible with Access 2000, but not Access 97.

Microsoft recommends that out-of-process clients use late binding to automate Access.

REFERENCES

For more information on Automation binding methods, please see the following article in the Microsoft Knowledge Base:

245115 INFO: Using Early Binding and Late Binding in Automation

Modification Type:MajorLast Reviewed:12/13/2004
Keywords:kbAutomation kbbug kbnofix KB246237
©2004 Microsoft Corporation. All rights reserved.