| Platform SDK: Exchange Server |
The client side of the Microsoft Exchange Server information store provider buffers calls to the MAPI Advise function, and does not send it to the server until it is forced through by a later function call. In other words, although there is no MAPI_DEFERRED_ERRORS flag on the Advise function, a call to Advise works as if this flag is available and always set.
This means that an application cannot simply call Advise and wait for notifications to appear. It must call Advise and then, for example, call IMAPIProps::GetProps on a property known not to be cached on the client. This GetProps call can be executed on any object, such as the information store itself.
An RPC can initiate the return of notifications, but an Advise call itself does not force an RPC.
If your application is about to make several function calls, one of which is Advise, make sure that Advise is not the last call. For example, this order is incorrect:
The following order is correct because at least one call after Advise causes an RPC:
If you are working with a table, you could also call the QueryRows function, which causes an RPC and forces any Advise requests to the server.
To summarize, call Advise in a way that you know causes the information store (server side) to receive the Advise call to make sure notifications are enabled, and then check that there is a mechanism by which the store sends notifications.