Export (0) Print
Expand All

3.2.5.4 Processing RopRestrict

When a RopRestrictROP request ([MS-OXCROPS] section 2.2.5.3) is received, the server MUST apply the restriction (2) to the table, and subsequent requests that operate on the table MUST consider the new restriction (2).

If a restriction (2) is applied to a table, the table MUST appear as if it only contains the rows that match the restriction (2).

When this ROP is sent, the server MUST invalidate all current bookmarks (2) 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 (2) is not specified), then the table MUST be considered as not having any restrictions (2).

If a RopRestrict ROP fails, the server SHOULD invalidate the table restriction (2) until a successful RopRestrict ROP request is made. The server can restore the previous restriction (2).

If the TBL_ASYNC bit of the RestrictFlags field is set, the server MAY<23> 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 (2) does not exist on the server.

Show:
© 2014 Microsoft