3

尽管在线阅读了大量可用资源,但我找不到明确的直接解释:

在什么情况下 和 的值PageingInfo.PageNumberPageingInfo.PagingCookie需要赋值?

例如:假设我们有 10,000 条唯一记录,我们想检索所有记录,但一次检索 200 条记录。我们是否必须迭代PageNumber(50 次迭代),还是仅使用PagingCookie?

现在,我想分享一下我在在线资源上发现的内容:

首先,许多在线资源链接到官方 MSDN 示例(对于 FetchXML: 1 , 2,对于 QueryExpression: 1 , 2),但是对于这个问题没有直接的答案。他们都遍历PageNumber,但据我了解(可能是错误的),一个 Page总是有 5000 条记录(或者是吗?)。

其次,我发现了这个使用的演示,从 40 条记录PagingCookie中提取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

因此,正如我在此示例中看到的那样,不需要使用页码,因为在 SQL 查询中只使用了分页 cookie

对这个问题有一个很好的澄清会很棒。

4

2 回答 2

0

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

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

在检索同一结果集的另一个页面时,客户端应简单地将 cookie 复制到FetchXMLQueryExpression中。

据我所知(在 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 命令修改最大页面大小。

于 2017-08-25T19:48:43.660 回答
0

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

查询中没有第 # 页:

ss1

分页 cookie 中的 ID 保持不变:

ss1

与页面 #:

ss3

身份证变更:

ss4

值得注意的是,如果您在不更改分页 cookie 中的页面或 ID 的情况下前进页面 #,

ss5

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

ss6

它必须对 SQL 记录集进行一些处理,因为它返回正确数量的记录(在本例中为 20),并且 ID 为高级:

ss7

于 2017-08-25T12:51:48.860 回答