The server maintains a fixed-size queue of notifications. When the queue limit of 64 notifications is exceeded, the information store provider first tries to collapse notifications. For example, notifications that describe the specific changes in a table are changed into TABLE_CHANGED notifications, which state simply that the table has changed. It no longer provides the row that has been added, deleted, or modified. At this point, the client must reload the entire table to ensure accuracy. When the queue limit is exceeded, it is also possible that some notifications are lost.
The TABLE_RELOAD flag indicates a need to re-read the table data and start over. When a client receives the TABLE_RELOAD event, it should assume that nothing about the table is still valid. All bookmarks, instance keys, short-term entry identifiers, and status and positioning information are obsolete.
In almost every case, an application should respond the same way to a TABLE_CHANGED event as to a TABLE_RELOAD event: namely, it should read all the table data again.