BUG: Access 2000 Object Model Breaks Binary Compatibility

ID: Q246237

The information in this article applies to:

Microsoft Access 2000

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.

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

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

The following problems have been identified with the Access 2000 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 because the methods have been mistakenly moved in Access 2000.

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 both versions.

All of the following controls for Access 2000 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 Access 2000.

RESOLUTION

Automation clients that want to Automate both Access 97 and Access 2000 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.

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:

Q245115 INFO: Using Early Binding and Late Binding in Automation

Additional query words:

Keywords : kbAccess kbAutomation kbGrpDSO
Version : WINDOWS:2000
Platform : WINDOWS
Issue type : kbbug