3.2.5.4 Processing RopRestrict
When a RopRestrict ROP request ([MS-OXCROPS] section 2.2.5.3) is received, the server MUST apply the restriction to the table, and subsequent requests that operate on the table MUST consider the new restriction.
If a restriction is applied to a table, the table MUST appear as if it only contains the rows that match the restriction.
When this ROP is sent, the server MUST invalidate all current bookmarks of the table and MUST move the cursor position to the beginning of the table.
If a RopRestrict ROP request is not sent (a restriction is not specified), then the table MUST be considered as not having any restrictions.
If a RopRestrict ROP fails, the server SHOULD invalidate the table restriction until a successful RopRestrict ROP request is made. The server can restore the previous restriction.
If the TBL_ASYNC bit of the RestrictFlags field is set, the server MAY<24> execute the ROP as a table-asynchronous ROP, as specified in section 3.2.5.1.
The RopRestrict ROP MUST be supported for contents tables, hierarchy tables, and rules tables.
The following specific error code applies to this ROP. For more details about ROP errors returned, see [MS-OXCDATA] section 2.4.
|
Error code name |
Value |
Description |
|---|---|---|
|
ecNotSupported |
0x80040102, %x02.01.04.80 |
The object on which this ROP was sent is not a contents table, hierarchy table, or rules table. |
|
ecConversationNotFound |
0x00000496, %x96.04.00.00 |
The conversation specified in the restriction does not exist on the server. |