SharePoint survey only returns 30 items

While working with surveys and modifying them, I’ve encountered the following issue: When a user uses the “Export to Spreadsheet” function offered by SharePoint, his/hers export will only contain a maximum of 30 items, even if the survey contains more than 30 responses.

The survey list is a special list. It’s impossible to add new views to the survey list, but it’s possible to modify the existing views because all they actually use is the list view web part. You can simply modify an existing view by clicking “Site Actions -> Edit Page”.

When we started working on the survey to alter some behaviour by using jQuery, we didn’t notice any difference at first. However, when a user started using the export functionality, we scratched our heads.

Checking out the source of the overview.aspx page made us much wiser. This is how a correct survey overview.aspx source looks like. We’ve opened up the page with SharePoint designer and switched to code view:

edit in advanced mode

correct survey view

Then we looked at our “corrupt” survey’s overview.aspx:

corrupt list view source

When you check the ListViewXml from the “bad” source, you’ll find a xml tag “RowLimit” set to 30. This is a standard value, but apparently the “corrupt” list view uses it to export all the results to excel. When you update this value to a higher number, the results will flow back in perfectly.

Similar problems have been reported on the following blog:


Lookup Field localization not working when using ContentTypeBinding

Whilst working with lookup fields, I noticed something strange when you separated the Fields and ContentType from your list and you try to use localization. Separating your content type and fields from your list basically means that you no longer work with a custom list definition, but you use ContentTypeBinding on a list instance to create your list.

Here’s an example on how the project is set up:


The red arrows point to the lookup list where I use the ContentType “LookUpContentType”, where a lookup field is referenced. This lookup field resides in the “Fields” element:

“Fields” Elements.xml

<?<span class="hiddenSpellError">xml version="1.0" encoding="utf-8"?>
  <Field Name="LookUpFieldInElements"

“LookUpContentType” Elements.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- Parent <span class="hiddenSpellError" pre="Parent ">ContentType</span>: Item (0x01) -->
<ContentType ID="0x01002846E06F521348B79F631D4D9E6A07CC" Name="LookUpContentType" Group="Custom Content Types" Description="My Content Type" Inherits="TRUE" Version="0">
<FieldRef ID="{32A4FE06-2745-40D0-B92C-76A58B16C7B0}" Name="LookUpFieldInElements" Required="TRUE" />

“LookUpListCTInstance” Elements.xml

<?xml version="1.0" encoding="utf-8"?>
Description="My List Instance with ContentTypeBinding"
<ContentTypeBinding ContentTypeId="0x01002846E06F521348B79F631D4D9E6A07CC" ListUrl="Lists/LookupListCT" />

The blue arrows point to a regular list definition which has a list instance included.

The Schema.xml of the “LookupList” list definition

      <ContentType ID="0x0100468fd589c1da4592929a6768ac144020" Name="ListFieldsContentType">
<FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" />
<FieldRef ID="{a51cabb2-7594-41db-8523-ea5de71e6202}" Name="LookUp" />
        ShowField="Title" />

When you take a look at the DisplayNames of both the LookupFields residing in Schema.xml and “Fields” Elements.xml, you’ll see that the value holds “$Resources:lookupfield,LookUp;”. So we’re trying to localize the LookupField’s column name.

I’ve added the following resource files where I can add my translations:



<data name="LookUp" xml:space="preserve">


<data name="LookUp" xml:space="preserve">
  <value>[ENG] LookUp</value>

<data name="LookUp" xml:space="preserve">
  <value>[NL] LookUp</value>

<data name="LookUp" xml:space="preserve">
  <value>[FR] LookUp</value>

Looks great! Let’s check out the result on our SharePoint lists:



Apparently there’s a bug when separating your LookupField from your Schema.xml where it will only use the English localization. So whenever you want to use LookupFields in custom lists, use the list definition way!

Using crawl rules to hide list view names

One of the things SharePoint search does, is showing almost everything it finds. Even names of views.

For instance you create a new view, named NewView, and when you search for “new” or “view”, SharePoint will return you http://sharepoint/lib/Forms/NewView.aspx in the search results. Do I want that? Hm, no it’s not really relevant to the search I’m making.

A solution to this problem is using crawl rules to exclude the /Forms/ bit. By adding *://*/Forms/* to the crawl exclude rule, nothing was crawled anymore. Strange. A quick test showed me that changing the rule to *://*/Forms/*.aspx made my search results appear again. Make sure to run a full crawl after you change any crawl rule to apply its effect.

0x80070057Bad parameter passed to Web Server Extensions

By using the UpdateListItems() method of the web service Lists.asmx, an update of a list item kept on failing with the following error:

0x80070057Bad parameter passed to Web Server Extensions. Check the information you entered and try again.

The XML passed to the web service was built up as followed:

<Method ID='1' Cmd='Update'>
   <Field Name='ID'>1</Field>
   <Field Name='Title'>Update</Field>

There was no real reason why the web service should fail updating the item. The update worked fine on other lists. Turned out that after fiddling and testing with the list, the field “ID” was turned into editable mode and showed up as a column when the list settings were checked.

When the XML is passed to the web service, it successfully finds the fields “ID” and “Title”, but both are updatable. There’s no real identification of the item that should be updated.

The solution for the problem described here, is to turn the field “ID” back to read only. This is possible through PowerShell:

$web = Get-SPWeb http://sharepoint
$list = $web.Lists["ListName"]

$list.Fields["ID"].ReadOnly = $true

Creating a cross site lookup field without code

There’s a high demand for using cross site lookup fields. Most solutions offered include deploying a solution or writing your own code. There is, however, a simple method for creating a cross site lookup field by using SharePoint’s own GUI.

In the following example I use 2 sites, http://sharepoint/Site with a custom list named “Values”. I added 3 items in the list as sample data:

main site

The other site is a subsite from the previous one, http://sharepoint/Site/Subsite. Here I added a custom list named “Using Lookup”:

sub site

Browse back to the main site, in my example http://sharepoint/Site, and click on Site Actions, Site Settings:

Site Actions Site Settings

On the site settings page navigate to the site columns gallery:

Site columns gallery

Click on the create button to create a new site column:

create new site column

Fill in a desired name:

site lookup column

Next, select the custom list “Values” at the properties and whatever you need to lookup:

site lookup column properties

Click on OK and navigate to your subsite’s custom list, in my example the list “Using Lookup”. Open up the list settings:

using lookup list settings

At the columns settings, click on “Add from existing site columns”:

list settings columns

Select the “Lookup Values” column and press the add button:

add lookup values column

Click OK, navigate to the list “Using Lookup” and add a new item. The lookup values from the topsite are now selectable!

new lookup item

As far as constraints go, they’re the same as every custom site column.

Using a lookup field on a choice field workaround

Unfortunately, it’s impossible to map a lookup field on a choice field. There’s a workaround, however, by using a calculated field which copies the information from the choice field. The look up field is then able to map the calculated field’s value.

Start out by creating 2 custom lists; One list where the choice and calculated columns reside:

create a custom list with content

And another list where the lookup will be done:

create a custom list with lookup

Navigate to the list with content, and click on the “List” contextual tab in the ribbon. With the list options open, click on the “Create Column” button. When the dialog pops up fill in the desired options and select “choice” as column type:

choice column

Click on OK. The choice column should now be added to your list. Click the “Create Column” button again, but now select “Calculated” as column type:

calculate column

Scroll down and reference the choice field in your calculation formula:

calculate column properties

Click OK. The calculated column should now be added to your list with content. Add a new item to check whether the calculation formula works:

custom list with content

Navigate to the list where the lookup will be made and create a new column. Fill in a desired name and select “Lookup” as column type:

lookup column

Scroll down again, and select your list with content where the lookup column should get its information. Next, select the title to be looked up and as you can see, the calculated column shows up as a selectable property:

lookup column properties

Finish adding the column by clicking OK. Whenever you add a new item to the lookup list and use the lookup column, the chosen choice field from the content list will be shown:

custom list with lookup content

In an ideal situation, Microsoft addresses this issue and makes choice fields able to be looked up in the near future.