Recently I met another frustrating limitation in SharePoint 2010.
I was working on a client side artifact that accesses a list with several Person or Group fields through ADO.NET Data Services. Running a fairly complex query resulted the infamous “An error occurred while processing this request.” response (System.Data.Services.Client.DataServiceQueryException). Checking the InnerException I found a System.Data.Services.Client.DataServiceClientException with a Message:
The request includes 9 $expand segment(s), but the maximum allowed is 7.
So my query contains too many Lookup / Person or Group fields. First I hoped there is a configuration option to help me out in the Resource Throttling settings page of the web application, similar to the List View Lookup Threshold (MaxQueryLookupFields property of SPWebApplication, see a useful post about it here: Throttling: New Features of List in SharePoint 2010 or another one here: Manage lists and libraries with many items), but I found none there.
Looking around the web I found that for MS Dynamics CRM 2011 this value is configurable (see MaxExpandCount here), at the same time it turned out the same value is hard-coded for SharePoint in the InitializeService method of ListDataService (Microsoft.SharePoint.Linq namespace in Microsoft.SharePoint.Linq.DataService assembly at GAC):
public static void InitializeService(DataServiceConfiguration config)
if (config == null)
throw new ArgumentNullException("config");
config.MaxBatchCount = 0x3e8;
config.MaxChangesetCount = 100;
config.MaxExpandCount = 7;
config.MaxExpandDepth = 7;
config.MaxObjectCountOnInsert = 100;
config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
Although one could create a customizable, derived service from ListDataService and listdata.svc, for this simple job I rather altered my query. The result might be worse in network usage due to multiple roundtrips, but at least does not exceed the limitation of $expand segments.
BTW, you can find a nice solution to workaround another limitation in ListDataService here:
I don’t see why SharePoint is limiting us by hard-coded values like this one. I assume, for lists having several hundreds of items in each the limitation of 7 expands might be too loose, while for lists only with a few items one might allow even 20 expands or more.