About Table Notifications
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.
Clients often rely on table notifications to learn of changes to objects instead of registering to receive notifications directly from the objects. Typical changes that cause notifications to be sent include the addition, deletion, or modification of a row and any critical error. When notifications arrive, clients can determine whether to make another call to reload the table.
Because table notifications are asynchronous, there are a few issues that can make handling notifications less than straightforward:
The data passed in the TABLE_NOTIFICATION structure might not represent the table's most current state. For example, a client might make a change to a message and then decide to delete it. The message store provider implementing the contents table that included the message sends two notifications: a TABLE_ROW_MODIFIED event followed by a TABLE_ROW_DELETED event. Depending on how the message store provider times notifications, the client might receive the TABLE_ROW_MODIFIED notification after the deletion of the row.
The column set included with a notification might be different from the table's current column set. MAPI requires that the notification column set match the column set that was in effect at the time that the notification was generated. Because it is possible for a client to call IMAPITable::SetColumns to alter the column set at any time — including after a notification — the two column sets may not be synchronized.
Table notifications are only sent for rows that are part of the view. That is, if a row is excluded from the view due to a restriction or because the table is in a collapsed state, no notification will be sent if that row changes. Also, no notifications are sent to inform a client about a change in category state.
Clients should be aware that not all tables support the TABLE_SORT_DONE notification and should be prepared to handle this condition by:
Forcing the sort to be synchronous.
Reloading the rows of the table when IMAPITable::SortTable returns.