PRB: E_FAIL on SaveChanges() with Too Many Properties (197145)
The information in this article applies to:
- Microsoft Extended Messaging Application Programming Interface (MAPI)
- Microsoft Exchange Server 5.5
This article was previously published under Q197145 SYMPTOMS
When adding named properties to a message, the following error may occur
when IMAPIProp::SaveChanges() is returned:
MAPI_E_CALL_FAILED or E_FAIL (0x80004005)
When calling the Update method of a Collaboration Data Objects (CDO)
Message object, after having added named properties through the Fields
collection, the following error may occur:
The client operation failed. [Microsoft Exchange Server Information
Store - [E_FAIL(80004005)]]
If the properties have been added through a custom Outlook form, the
following error may display in Outlook when you attempt to save or send the
message:
The operation failed.
CAUSE
Message property mappings are stored in a single record in the Jet
database. A Jet record is currently fixed in size at 4K. Since the record
is fixed in size, only a finite number of properties can be stored on the
message. You can fit approximately 300-400 properties before exhausting the
space in the record. The number of properties that can exist on the message
will depend on the property types of the properties as well as the amount
of data in each property.
In the case of a custom Outlook form, the data for the form is stored in a
message. Every Outlook control that is bound to a data field consumes a
small amount of space in the message for a property mapping. (These data
fields represent custom or named properties on a message.)
RESOLUTION
The solution is to reduce the number of user-defined properties stored on
the message (or form). Here are a couple of suggestions:
- You may consider consolidating data into fewer fields and then parsing
and displaying them in multiple controls. This may or may not work,
depending on the nature of your data and how it will be used.
- You may also consider splitting a complex form into multiple forms to
reduce the number of fields for any one form (and thereby reduce the
number of properties for any one message). This may increase the
complexity of your business processing, but is more supportable.
STATUS
This behavior is by design.
Modification Type: | Minor | Last Reviewed: | 8/25/2005 |
---|
Keywords: | kbMsg kbprb KB197145 |
---|
|