何时指定PagingInfo.PagingCookie和PagingInfo.PageNumber

Question

虽然在线阅读了大量可用资源，但我找不到明确的直接解释：

什么情况下需要同时赋值

PageingInfo.PageNumber

和

PageingInfo.PagingCookie

的值？

例如：假设我们有 10,000 条唯一记录，我们希望检索所有这些记录，但一次检索 200 条记录。 我们是否必须迭代

PageNumber

（50 次迭代），还是仅使用

PagingCookie

就足够了？

现在，我想分享我在在线资源中发现的内容：

首先，许多在线资源链接到官方 MSDN 示例（对于 FetchXML：1、2，对于 QueryExpression：1、2），但这个问题没有直接答案。他们都迭代

PageNumber

，但据我了解（可能是错误的），一个页面总是有5000条记录（或者是吗？）。

其次，我找到了this使用

PagingCookie

的演示，从40条记录中获取记录6-10条：

<fetch mapping="logical" count="5" page="2" paging-cookie="&lt;cookie page=&quot;1&quot;&gt;&lt;new_parentrecordid last=&quot;{F8DAB1AA-3A0F-E411-8189-005056B20097}&quot; first=&quot;{F8DAB1AA-3A0F-E411-8189-005056B20097}&quot; /&gt;&lt;/cookie&gt;" version="1.0">
    <entity name="new_parentrecord">
        <attribute name="new_name" />
        <link-entity name="new_childrecord" from="new_parentaid" to="new_parentrecordid">
            <attribute name="new_childrecordid" />
            <attribute name="new_name" />
        </link-entity>
    </entity>
</fetch>

然后，解释将上面的内容翻译成以下 SQL 查询：

select top 6 "new_parentrecord0".new_name as "new_name"
            , "new_parentrecord0".new_parentrecordId as "new_parentrecordid"
            , "new_childrecord1".new_childrecordId as "new_childrecord1.new_childrecordid"
            , "new_childrecord1".new_name as "new_childrecord1.new_name" 
from
     new_parentrecord as "new_parentrecord0" 
    join new_childrecord as "new_childrecord1" on ("new_parentrecord0".new_parentrecordId  =  "new_childrecord1".new_ParentAId) 
where
     ((("new_parentrecord0".new_parentrecordId > '01DBB1AA-3A0F-E411-8189-005056B20097'))) 
order by
     "new_parentrecord0".new_parentrecordId asc

因此，正如我在这个示例中看到的那样，不需要使用页码，因为只使用分页 cookie 来生成 SQL 查询。

如果对这个问题有一个很好的澄清那就太好了。

Answer 1

我的经验和我刚刚所做的额外研究表明，是的，我们确实需要迭代所有页面。虽然页码永远不会进入 SQL 查询，但它控制 SQL 将在其过滤器中使用哪个 ID。

查询中没有页号：

分页 cookie 中的 ID 保持不变：

页码：

ID变更：

还值得注意的是，如果您前进页面#而不更改分页 cookie 中的页面或 ID，

系统使用分页cookie的最后一个ID并扩展SQL“top”参数来获取您请求的页数：

并且它必须对 SQL 记录集进行一些处理，因为它返回正确数量的记录（在本例中为 20），并且具有 ID 的高级：

Answer 2

PagingCookie 是服务器已传递给客户端的结果集的只读标识符。其目的是优化数据检索，不应修改。 PagingCookie 基本上告诉服务器可以粗略地找到指定页面的开始和结束位置。

我假设它使 CRM 服务器能够使用缓存的查询结果集。当使用分页 cookie 对结果集进行分页时，我注意到服务器仅提交一次 SQL 查询（即，当它接收到没有分页 cookie 的查询时），并尽可能从内存中传递后续页面。

当检索同一结果集的另一个页面时，客户端只需将 cookie 复制到

FetchXML 或 QueryExpression 即可。

据我所知（在 Dynamics CRM 2016 (V8.2) 上测试它）这也适用于联接。

我怀疑您显示的 SQL 查询实际上是篡改 PagingCookie 的结果：服务器在其缓存中找不到 cookie，假设原始结果集已被刷新，并且当它构建新的 SQL 查询时，它完全依赖于cookie 声明的边界的正确性。因此出现了意想不到的

where

条款。

结论

始终使用

page

 属性 (

FetchXML

) 或 

PageInfo.PageNumber

 属性 (

QueryExpression

)。切勿修改

PagingCookie，只需将其复制到后续页面请求中即可。

未指定页面大小（

count

属性）时，默认最多为 5,000 行。当预期结果集大于该值时，需要迭代所有可用页面。

当您使用 Dynamics CRM On Premise 时，您可以使用 PowerShell 命令修改最大页面大小。