Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

PRB: E_FAIL on SaveChanges() with Too Many Properties


View products that this article applies to.

This article was previously published under Q197145

↑ Back to the top


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.

↑ Back to the top


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.)

↑ Back to the top


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.

↑ Back to the top


Status

This behavior is by design.

↑ Back to the top


Keywords: KB197145, kbprb, kbmsg

↑ Back to the top

Article Info
Article ID : 197145
Revision : 6
Created on : 8/25/2005
Published on : 8/25/2005
Exists online : False
Views : 392