Dynamics CRM 2011 Quick Find Performance & Records Per Page Setting

Imagine this scenario in Dynamics CRM 2011. When a CRM user does search for *cond, for example, in the quick find box on Accounts filtered view, like below screenshot, the IE window hangs and after approx. 2mins 30secs the IE window comes back from un-responding and displays the result from the search.


When looking in the hang dump file in Debug Diag for example, we could see the below in one of the threads:

+0x008 bstrVal
0x0bc3deec  "<grid><sortColumns>name&#58;1</sortColumns><pageNum>1</pageNum><recsPerPage>50</recsPerPage><dataProvider>Microsoft.Crm.Application.
< cols/><max>1</max><refreshAsync>False</refreshAsync><pagingCookie/><enableMultiSort>true</enableMultiSort><enablePagingWhenOnePage>
&#123;2D1187C4-23FE-4BB5-9647-43BB1C6DDBD1&#125;</viewid><viewtype>1039</viewtype><RecordsPerPage>50</RecordsPerPage><viewTitle>Aktive Firmen</viewTitle><otc>1</otc><otn>account</otn><entitydisplayname>Firma</entitydisplayname><titleformat>&#123;0&#125; &#123;1&#125;</titleformat><entitypluraldisplayname>Firmen</entitypluraldisplayname><isWorkflowSupported>true
< /isWorkflowSupported><fetchXmlForFilters>&#60;fetch


The setting in Personal options – General - Records per page was set to 50. When this was changed to 250 records per page (as per below), and performed a quick search again on Accounts filtered view for *cond the results were returned in 2 seconds, instead of the 2mins 30 secs.



When comparing the SQL profiler traces, when set for 50 records per page it queries:

exec sp_executesql N'select top 51 "account0".Name as "name"

When set for 250 records per page it queries:

exec sp_executesql N'select top 251 "account0".Name as "name"

This indeed shows the increased query performance when set at 250 records per page and not as many queries needed to get the results back.

When looking at the execution plan of both, you may see that the quick search when set to 50 records per page has a lot of nested loops and seeks, whereas when set to 250, there are no nested loops and scans instead of seeks.

You may also see that on the execution plan in SQL for the search when set at 50 records per page, it suggests to add a missing index such as below example:




CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]

ON [dbo].[AccountBase] ([StateCode])

INCLUDE ([AccountId],[TerritoryId],[Name],[AccountNumber],[WebSiteURL],[Telephone1],[TransactionCurrencyId])




In general practice, using an astrix (*) at the start of a search is not performance efficient.

When performing a quick find with a wildcard, it does not take advantage of any indexes, so you will never achieve optimal performance with this type of search.  It is recommended to avoid wildcard searches when at all possible during a quick find search. 


Best Regards

Dynamics CRM Support Team


Share this Blog Article on Twitter

Follow Us on Twitter

Comments (2)

  1. Philip Verlinden says:


    What's the (technical) reason on having different the execution plans between 50 or 250 records?

    Is this also applicable for CRM 2013?

    Best regards,


  2. Predesh CV says:

    Is there an option to make refreshAsyn to true in the below query.

    +0x008 bstrVal

    0x0bc3deec  "<grid><sortColumns>name:1</sortColumns><pageNum>1</pageNum><recsPerPage>50</recsPerPage><dataProvider>Microsoft.Crm.Application.


    < cols/><max>1</max><refreshAsync>False</refreshAsync><pagingCookie/><enableMultiSort>true</enableMultiSort><enablePagingWhenOnePage>


Skip to main content