PidTagRecordKey Canonical Property
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
Contains a unique binary-comparable identifier for a specific object.
Associated properties: |
PR_RECORD_KEY |
Identifier: |
0x0FF9 |
Data type: |
PT_BINARY |
Area: |
ID properties |
Remarks
This property facilitates locating references to an object, such as finding its row in a contents table. This property cannot be used to open an object; use the entry identifier for that purpose.
An attachment subobject should be uniquely identified within a message by this property. This identifier is the only attachment characteristic guaranteed to stay the same after the message is closed and reopened. The store provider must preserve this property across sessions to ensure this guarantee.
For folders, this property contains a key used in the folder hierarchy table. Typically this is the same value as that provided by the PR_ENTRYID (PidTagEntryId) property.
For message stores, this property is identical to the PR_STORE_RECORD_KEY (PidTagStoreRecordKey) property.
In a message store object, this property should be unique across all store providers. One way to do this is to combine the value of the PR_MDB_PROVIDER (PidTagStoreProvider) property for the store (unique to that provider type) with a GUID structure or other value unique to the specific message store.
This property is always available through the IMAPIProp::GetProps method following the first call to the IMAPIProp::SaveChanges method. Some providers can make it available immediately after instantiation.
A client or service provider can compare values from this property by using memcmp. This is not possible for entry identifier values. However, this property is guaranteed to be unique within the same message store or address book container; two objects from different containers can have the same value of this property.
One distinction between the record and search keys is that the record key is specific to the object, whereas the search key can be copied to other objects. For example, two copies of the object can have the same PR_SEARCH_KEY (PidTagSearchKey) value but must have different values for this property.
The following table summarizes important differences among PR_ENTRYID, PR_SEARCH_KEY (PidTagSearchKey) and this property.
Characteristic |
PR_ENTRYID |
PR_RECORD_KEY |
PR_SEARCH_KEY |
|---|---|---|---|
Required on attachment objects |
No |
Yes |
No |
Required on folder objects |
Yes |
Yes |
No |
Required on message store objects |
Yes |
Yes |
No |
Required on status objects |
Yes |
No |
No |
Creatable by client |
No |
No |
Yes |
Available before a call to SaveChanges |
Maybe |
Maybe |
Messages Yes Others Maybe |
Changed in a copy operation |
Yes |
Yes |
No |
Changeable by a client after a copy |
No |
No |
Yes |
Unique within ... |
Entire world |
Provider instance |
Entire world |
Binary comparable (as with memcmp) |
No -- use IMAPISupport:: CompareEntryIDs |
Yes |
Yes |
Related Resources
Protocol Specifications
[MS-OXPROPS]
Provides references to related Exchange Server protocol specifications.[MS-OXCMSG]
Handles message and attachment objects.[MS-OXOABK]
Specifies the properties and operations for lists of users, contacts, groups, and resources.
Header Files
Mapidefs.h
Provides data type definitions.Mapitags.h
Contains definitions of properties listed as alternate names.