SharePoint Designer Support Team Blog

Providing insight on hot and common issues, supportability, and how-to's for Microsoft SharePoint Designer. Coming direct from the support engineers themselves. Read who we are.

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

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 fix is 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.
 

Published Tuesday, June 17, 2008 4:26 PM by michmon

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Kosher said:

That doesn't work, among many other things.  I tried the steps on the new item form, removed the 0, and the form takes forever to load still.  I have lots of form fields with dynamic data but this is nuts.  How in the world is it so slow?

August 1, 2008 3:18 AM
 

Mark Arnold said:

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

September 7, 2008 1:53 PM
 

erugalatha said:

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.

November 8, 2008 9:21 AM
 

Dustan Archer said:

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.

December 4, 2008 2:47 PM
 

Oleg said:

Its open library with 10 items around 5 MINUTES!!!!

HOW WORK WITH IT????

December 10, 2008 12:58 PM
 

wattsonlosen said:

works fine for me also.

thank you very much

February 12, 2009 8:16 AM
 

Jesse McNulty said:

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.

March 10, 2009 1:12 PM
 

michmon said:

@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.

March 10, 2009 2:31 PM
 

Katie said:

How do I access the Common Data View Task in order to edit the parameters?

June 19, 2009 8:12 AM
 

Bazin Makonnen said:

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

July 14, 2009 2:03 PM
 

Jeff Barton said:

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?

October 30, 2009 12:42 PM
 

Jeff Barton said:

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.

November 4, 2009 12:02 AM

Leave a Comment

(required) 
(optional)
(required) 

  
Enter Code Here: Required
Submit

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker