ODATA has a limitation where it can return only 50 records at a time. You can ofcourse query more than that but it would be in batches of 50 records at a time.<\/p>\n
Fetch XML queries on the other hand will allow you to read upto 5000 records in one go with the ability to read the next 5000. Since requesting 5000 records at a time may not really be a good idea because of the network resources that would use and potentially slow down or even time out depending on the network speeds, it is always a good idea to read data in small manageable sets of records. Fetch queries when executed return paging cookies when you implement paging and this helps you to implement a system where you would like to read a fixed count of records and provide a next\/prev button to access additional records.<\/p>\n
Query Records using Fetch<\/h2>\n
<fetch mapping=”logical” output-format=”xml-platform” version=”1.0″ page=”1″ paging-cookie=”” ><\/p>\n
<entity name=”account” ><\/p>\n
<attribute name=”name” \/><\/p>\n
<attribute name=”address1_city” \/><\/p>\n
<order descending=”false” attribute=”name” \/><\/p>\n
<filter type=”and” ><\/p>\n
<condition attribute=”ownerid” operator=”eq-userid” \/><\/p>\n
<condition value=”0″ attribute=”statecode” operator=”eq” \/><\/p>\n
<\/filter><\/p>\n
<attribute name=”primarycontactid” \/><\/p>\n
<attribute name=”telephone1″ \/><\/p>\n
<link-entity visible=”false” name=”contact” link-type=”outer” to=”primarycontactid” from=”contactid” alias=”accountprimarycontactidcontactcontactid” ><\/p>\n
<attribute name=”emailaddress1″ \/><\/p>\n
<\/link-entity><\/p>\n
<attribute name=”industrycode” \/><\/p>\n
<attribute name=”donotbulkemail” \/><\/p>\n
<attribute name=”creditonhold” \/><\/p>\n
<attribute name=”accountid” \/><\/p>\n
<\/entity><\/p>\n
<\/fetch><\/p>\n
The above code works fine as long as there are less than 5000 records in the system. When the records fetched count went above 5000+ records we started getting following error:<\/p>\n
So if you notice in our above fetch xml we are providing \u201cpaging-cookie\u201d as blank. So once the records retrieved count goes above 5000+ records we started getting the above shown error. For Fetch to bring records above 5000+ it requires paging-cookie to be set in the fetch tag<\/p>\n Where do we find the paging cookie?\u00a0 The answer is fetch response. Whenever we make a fetch request the response which we get back from fetch has paging-cookie in it. We need to extract that paging-cookie from response which we can send to our next page fetch request. In addition to paging-cookie we also get \u201cMoreRecords\u201d which is Boolean which tells us if there are any more records to fetch.<\/p>\n When we are on first page we provide the paging-cookie as blank as the first page doesn\u2019t need a paging-cookie. When the fetch query is executed it brings the page-cookie with it in the resultant response which looks like this:<\/p>\n “<cookie page=\\”1\\”><name lastnull=\\”1\\” firstnull=\\”1\\” \/><accountid last=\\”{98B36F67-3A21-E511-80FC-C4346BAD2660}\\” first=\\”{A6B16F67-3A21-E511-80FC-C4346BAD2660}\\” \/><\/cookie>”<\/p>\n To get this page-cookie from response we extract it from resultant fetch response as follows:<\/p>\n Var pagecookie = $(resultXml).find(“a\\\\:PagingCookie”).eq(0)[0].text;<\/p>\n You can find that since we are on first page it returns the page as \u201c1\u201d. Since the fetch is for \u201cAccount\u201d entity it returns the first accountid and last accountid for that page in page-cookie. When we request for the next page we provide this page-cookie from first page to the next page fetch query request.<\/p>\n In the same way we can extract \u201cMoreRecords\u201d as follows:<\/p>\n Var moreRecords = $(resultXml).find(“a\\\\:MoreRecords”).eq(0)[0].text<\/p>\n This returns \u201ctrue\u201d or \u201cfalse\u201d which helps us to determine if we reached last page or still there are any records to fetch.<\/p>\n var xmlDocument = parser.parseFromString(fetchxml, “text\/xml”);<\/p>\n var fetch = $(xmlDocument).find(‘fetch’);<\/p>\n fetch.attr(‘page’, page);<\/p>\n fetch.attr(‘count’, pageCount);<\/p>\n fetch.attr(‘paging-cookie’, pagingCookie);<\/p>\n In above code we are providing \u201cpagingCookie\u201d variable to which we set the page-cookie which we get from response in fetch attribute along with page and pagecount.<\/p>\n So now when you checkout the fetch query it be as follows :<\/p>\n <fetch count=”250″ mapping=”logical” output-format=”xml-platform” version=”1.0″ page=”18″ paging-cookie=”<cookie page="1"><name lastnull="1" firstnull="1" /><accountid last="{98B36F67-3A21-E511-80FC-C4346BAD2660}" first="{A6B16F67-3A21-E511-80FC-C4346BAD2660}" /></cookie>” \/><\/cookie>”><\/p>\n <entity name=”account” ><\/p>\n <attribute name=”name” \/><\/p>\n <attribute name=”address1_city” \/><\/p>\n <order descending=”false” attribute=”name” \/><\/p>\n <filter type=”and” ><\/p>\n <condition attribute=”ownerid” operator=”eq-userid” \/><\/p>\n <condition value=”0″ attribute=”statecode” operator=”eq” \/><\/p>\n <\/filter><\/p>\n <attribute name=”primarycontactid” \/><\/p>\n <attribute name=”telephone1″ \/><\/p>\n <link-entity visible=”false” name=”contact” link-type=”outer” to=”primarycontactid” from=”contactid” alias=”accountprimarycontactidcontactcontactid” ><\/p>\n <attribute name=”emailaddress1″ \/><\/p>\n <\/link-entity><\/p>\n <attribute name=”industrycode” \/><\/p>\n <attribute name=”donotbulkemail” \/><\/p>\n <attribute name=”creditonhold” \/><\/p>\n <attribute name=”accountid” \/><\/p>\n <\/entity><\/p>\n <\/fetch><\/p>\n Note:<\/strong><\/p>\n Make sure to encode the fetchxml request to cover for any special characters in the data. Let us explain with an example, for one of the result sets of the above fetch we found the paging-cookie received a special character \u2013 single quote (\u2018) in one of the records name field. This field was referenced in the paging-cookie.<\/p>\n Example:<\/p>\n “<cookie page=\\”2\\”><fullname last=\\”Susan\u2019s Burk (sample)\\” first=\\”Rene Valdes (sample)\\” \/><contactid last=\\”{349DB5FF-DA1B-E511-80F1-C4346BACD1A8}\\” first=\\”{2E9DB5FF-DA1B-E511-80F1-C4346BACD1A8}\\” \/><\/cookie>”<\/p>\n In above example you can see that the fullname last=\\”Susan\u2019s Burk (sample)\\” has (\u2018s). This (\u2018) used to break the fetchxml and hence started throwing \u201cPage Cookie Malformed<\/strong>\u201d exception when trying to execute fetchxml request.<\/p>\n To resolve this you need to encode the paging-cookie before it is insert in the fetch xml.<\/p>\n Using the paging-cookie you can traverse forward to the next set of results. But if you want to implement the previous button or you want to allow navigation to a specific page, you need to make sure you store the paging-cookie received for each of the pages.<\/p>\n To deal with this you can save the page-cookie for example in the array for the pages which you move forward and use this later to get the page-cookie for that particular page when moving backward in paging.<\/p>\n Using Paging-cookies effectively, you can implement paging without actually retrieving all the records at one-go. Query records only when requested and display for better performance results.<\/p>\n Get optimum visualization of Dynamics 365 CRM data with –<\/em> Introduction: There are multiple ways provided in Dynamics CRM SDK to query and read data like Using ODATA Using FetchXML Using Query object ODATA has a limitation where it can return only 50 records at a time. You can ofcourse query more than that but it would be in batches of 50 records at a\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":13,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[19,21,22,24,33,39,42],"tags":[395,592,597],"class_list":["post-1489","post","type-post","status-publish","format-standard","hentry","category-dynamics-crm","category-dynamics-crm-2013","category-dynamics-crm-2015","category-dynamics-crm-2016","category-javascript","category-miscellaneous","category-plugin","tag-crm-2013-dynamics-crm-2013","tag-dynamics-crm","tag-dynamics-crm-2015"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/posts\/1489","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/comments?post=1489"}],"version-history":[{"count":0,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/posts\/1489\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/media?parent=1489"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/categories?post=1489"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/tags?post=1489"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"report\"](\"https:\/\/www.inogic.com\/blog\/wp-content\/uploads\/2015\/07\/report4.png\")
<\/a><\/p>\nSetting the Paging Cookie<\/h2>\n
Updated Code<\/h2>\n
Traversing backwards<\/h2>\n
Conclusion<\/h2>\n
\nKanban Board<\/a> <\/strong>\u2013 Visualize Dynamics 365 CRM data in Kanban view by categorizing entity records in lanes and rows as per their status, priority, etc.<\/em>
\nMap My Relationships<\/a><\/strong> \u2013 Map My Relationships \u2013 Visualize connections and relationships between Dynamics 365 CRM entities or related records in a Mind Map view.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"