Microsoft KB Archive/197145

= PRB: E_FAIL on SaveChanges with Too Many Properties =

Article ID: 197145

Article Last Modified on 8/25/2005

-

APPLIES TO


 * Microsoft Messaging Application Programming Interface
 * Microsoft Exchange Server 5.5 Standard Edition

-



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.

Keywords: kbmsg kbprb KB197145

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.