MAPI property truncated when accessed using QueryRows

Please bear with me, my MAPI knowledge is minimal and my C++ skills rudimentary ...

I have a program that reads all possible calendar appointments from an Exchange server using MAPI. Things are working fine except for one strange situation.

If a recurring appointment has a large number of exceptions, then it seems as if the RecurrenceState property I'm getting from MAPI has been truncated to 1200 bytes. I can see in OutlookSpy that there are actually 1400 bytes. (Weird coincidence, both numbers being multiples of 100?)

The appointments are accessed by setting up something called a SizedSPropTagArray for 10 specific properties, one of which is RecurrenceState, and then doing a QueryRows operation. When I access the Value.bin.cb field for that property it is usually correct, but apparently contains 1200 for this particular property when it should be 1400.

Hope someone has a suggestion - TIA.

EDIT:

Dmitry, you say "Before you read the property value, do you check that the type is still PT_BINARY? Or does it get changed to PT_ERROR?"

I can't see how I should do this. I'm doing a QueryRows to get up to 100 appointments at a time. Then I loop through the LPSRowSet to process the results of the query, i.e., the up to 100 SRow objects. So to process the RecurrenceState I'm using sRow.lpProps[columnIndex], which provides an SPropValue. Now, there doesn't seem to be anything here that indicates the type of the returned property. The .ulPropTag field correctly contains the id of the RecurrenceState property, and .Value.bin.cb provides a length, usually correct but when the data is very long it is a lower value. What should I be testing to see if the error you're describing has occurred? Thanks.

EDIT 2:

Dmitry, I really appreciate your help, and I'm sure your basic idea must be correct. But unfortunately I'm not getting anywhere with testing for the error situation when it occurs.

I've now been able to reproduce the situation on our own Exchange server, the only difference being that for our Exchange server the limit for the RecurrenceState data is apparently 510 bytes, instead of 1200 bytes as seen at our customer's installation.

The following are some copy-and-paste captures of data in the program when running under Visual Studio debugger. The first from a normal recurring appointment whose exception data does not get truncated:

   sRow.lpProps[recurrenceInfoIndex].ulPropTag = 0x818b0102
   sRow.lpProps[recurrenceInfoIndex].Value = {i=0x01da l=0x000001da ul=0x000001da ...}

The next is for the appointment that has so many exceptions that the RecurrenceState data gets truncated:

   sRow.lpProps[recurrenceInfoIndex].ulPropTag = 0x818b0102
   sRow.lpProps[recurrenceInfoIndex].Value = {i=0x01fe l=0x000001fe ul=0x000001fe ...}

Note that .ulPropTag is identical to the OK appointment, and the data length is 开发者_Python百科0x1fe = 510, although I know that it is actually more.

I'm wondering, is there maybe some switch I should be setting to indicate that I want feedback about this kind of error?

Or is there something else I've misunderstood?

Thanks.

---

MAPI tables truncate large string properties. Large binary properties are not returned at all. Before you read the property value, do you check that the type is still PT_BINARY? Or does it get changed to PT_ERROR? To open large binary properties, you need to open the corresponding IMessage and open the property as IStream (IMessage::OpenProperty).

---

I would consider looking at Stephen Griffin's http://mfcmapi.codeplex.com/ which contains complete source code - you can use the mfcmapi application to view the required pst/folder/message/property and then review the code to see the MAPI calls required.