ContactItem Help Clarification

[George]

The ContactItem Class in Outlook is a beautiful and powerful thing.
I'm curious: How does Outlook actually store the contact data,
for example, with respect to:

BusinessAddress
BusinessAddressCity
BusinessAddressPostalCode
BusinessAddressState
BusinessAddressStreet
etc.

Is the info stored
a) unparsed in BusinessAddress
or
b) parsed in each of the component parts,
or
c) redunantly, in both.

The help has the following remark:
Remarks
This property is parsed from the BusinessAddress property, but may be
changed or entered independently should it be parsed incorrectly. Note that
any such changes or entries to this property will be overwritten by any
subsequent changes or entries to the BusinessAddress property
----------------------------------------------------------------------
I think this means that the address is ONLY stored unparsed in
BusinessAddress, and the components are parsed from that into City, State,
etc.

I'm curious because I know that Microsoft would have made that decision
carefully, and knowing how they made it might help me design unrelated
database tables containing addresses. I would take less space to store only
unparsed BusinessAddress, but most databases (in my experiences) aren't
organized that way.

Thanks in advance for your insight.
George

 

[Sue Mosher [MVP-Outlook]]

c) Both. You can see this clearly with the Outlook Spy and MFCMAPI.exe tools.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[George]

Thank you.
That surprised me.
Does that mean that the entire ContactItem is stored as one big flat record?

 

[Sue Mosher [MVP-Outlook]]

It is dangerous to make analogies between Outlook and databases, because you can lose a lot of the key Outlook concepts in the process. For example, Outlook data is semi-structured, in that a folder not only can hold nonhomogeneous items but can have situations where some items are similar in most of their properties, but differ in the custom properties they contain. Better to think of it in terms of object and properties, some of those properties being objects with their own properties (such as Recipients and Attachments). I strongly recommend getting one of the tools I mentioned if you want to explore these concepts further.
--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[George]

Thank you.
Will do.

It is dangerous to make analogies between Outlook and databases, because you can lose a lot of the key Outlook concepts in the process. For example, Outlook data is semi-structured, in that a folder not only can hold nonhomogeneous items but can have situations where some items are similar in most of their properties, but differ in the custom properties they contain. Better to think of it in terms of object and properties, some of those properties being objects with their own properties (such as Recipients and Attachments). I strongly recommend getting one of the tools I mentioned if you want to explore these concepts further.
--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers