Compartilhar via

How to fix: Slow page loads when opening pages that have custom new item forms [DataFormWebPart] for large lists [around 6000 items]

  • Artigo

Symptoms:

After creating a custom new item form for a SharePoint list having a very large number of items, the new item form will take a very long time to load at browse time. There are no error messages.

Cause:  

The issue happens because the default value "0" of the ListItemID parameter of the data source in the new item form causes a very resource intensive query to be run at page load time. This causes the perfiormance issue during page load. The reason we include all those parameters is to make the datasourcecontrol extensible in design time. The datasourcecontrol can be used by another webpart or view on the page and it could still work. If you don’t need those scenarios, then removing them should still work in runtime.

Workaround:

  1. Using the "Common Data View Tasks" pane for the new item form, click on "Parameters" to open the "Data View Parameters" dialog box.
  2. Select ListItemID and delete "0" in the Default Value input box.
  3. Leave the default value of ListItemID blank and click on OK.
  4. Save the page, and browse to it.

Additional Advice / Tip:

When working with large data sets you may experience other slowness in SharePoint Designer while working with data views. In those situations, you may see SharePoint Designer as non-responsive for several seconds after changes are made and / or may seem very sluggish once it's responding. Quick fixis to click "Common Data View Tasks" pane for the data view, and select "Show with sample data". Instead of showing all of the data from the data source, it limits it to 5 sample items.

Comments

  • Anonymous
    July 31, 2008
    The comment has been removed

  • Anonymous
    September 07, 2008
    I think I found something that can help further.  It looks like when you close a webpart through the browser, the webpart will still hang around in the background AND query list data even though it's not visible in the browser.  I discovered this in SPD when I opened the default.aspx and found HUGE amounts of discussion list data being returned from previous webparts that I'd added, then closed thinking they were gone.  They appeared greyed out in SPD because of their closed status.  When I deleted all these lingering webparts my page loads considerably faster in SPD and the browser. Mark

  • Anonymous
    November 08, 2008
    I've tried lots of things to speed up SPD including your steps above.  Nothing works - it is just dog slow! Microsoft need to take another look at it as sometimes it is unusable even with a list with a small number of rows.

  • Anonymous
    December 04, 2008
    Works great for me. 3 of the 33 fields are multiple value choice fields with 2133 records at this time. Was taking 1 to 5 mins to load. Now the load times are instantaneous. Thanks again.

  • Anonymous
    December 10, 2008
    Its open library with 10 items around 5 MINUTES!!!! HOW WORK WITH IT????

  • Anonymous
    February 12, 2009
    works fine for me also. thank you very much

  • Anonymous
    March 10, 2009
    Seems like if you are using a data source such as Web Service no matter how many balues are displayed the page is very very slow.

  • Anonymous
    March 10, 2009
    @Jesse: it's not so much how many values are displayed, as it is the number of items returned. If you apply XSLT filtering, it will take the full set of items (potentially thousands) and then filter. Alternativley, if you filter at the datasource level, and limit the number of items actually returned, you should see a perf increase.

  • Anonymous
    June 19, 2009
    How do I access the Common Data View Task in order to edit the parameters?

  • Anonymous
    July 14, 2009
    Open up your ASPX page, click on your custom form and then Click on the Common Data View Tasks button in the top-right hand corner. Bain Makonnen

  • Anonymous
    October 30, 2009
    I'm having this problem with OOB pages i.e. the list form web part and not the data form web part.  The 'edit parameters' option does not exist for list form web parts.  Any ideas?

  • Anonymous
    November 03, 2009
    I narrowed my problem down to the multi-valued lookup column in my list.  If I uncheck the option to "allow multiple values" for that column, the problem goes away.  I've scoured the interweb to find a solution to this, but all I find is advice on filtering views/webparts, using folders to partition the list into chunks < 2000, and indexing frequently used columns.  The latter doesn't work on this breed of column, and indexing the column that it points to doesn't help either.  Any advice or findings regarding the multi-valued lookup column and large lists would be greatly appreciated.

  • Anonymous
    August 29, 2012
    Hey michmon; this worked for me thank you somuch