3.2.5.3 Processing RopSortTable

When a RopSortTable ROP request ([MS-OXCROPS] section 2.2.5.2) is received, the server MUST apply the sort order to the table, and subsequent requests sent that operate on the table MUST consider the new sort order.

If a sort order is already specified, the new sort order returned with the ROP response MUST replace the old sort order.

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 RopSortTable ROP request is not sent (a sort order is not specified), then the table MUST be considered as having the default sort order. Default sort order is undefined.

If the RopSortTable ROP fails, the server SHOULD invalidate the table sort order until a successful RopSortTable ROP is made. The server can restore the previous sort order.

If the TBL_ASYNC bit of the SortTableFlags field is set, the server can execute the ROP as a table-asynchronous ROP,<23> as specified in section 3.2.5.1.

The RopSortTable ROP MUST be supported for contents tables.

If a multivalue property has the MultivalueInstance bit set in the SortOrder structure, the server MUST sort the rows that have multiple values for the property according to the single values used in the multivalue instances in subsequent RopQueryRows ([MS-OXCROPS] section 2.2.5.4), RopFindRow ([MS-OXCROPS] section 2.2.5.13), or RopExpandRow ([MS-OXCROPS] section 2.2.5.16) ROPs that are executed on the table.

The following specific error codes apply to this ROP. For more details about ROP errors returned, see [MS-OXCDATA] section 2.4.