I am unsuccessfully attempting to cause an SPQueryThrottledException locally in order to debug a problem a customer is having.

I'm using SPSiteDataQuery to query several sites which contain 4000 to 8000 items each, totalling over 43000. The query is being run against an elevated instance of the root SPWeb of the site collection.

The query is filtered using both the <Webs> and <Lists> elements, but not by any other attribute, and is not querying recursively. It runs at the Site Collection scope.

The query has run successfully when triggered by user accounts of Contribute level permissions and higher (although this is redundant given the elevation). Lower permission levels would fail for other reasons.

The twist is this: When running locally the query succeeds, but when running in the customer's live instance, the query fails when more than 5000 items are queried in total.

We both have the same Throttling settings:

  • 5000 normal limit
  • 20000 admin/audit limit
  • Out of hours query limit removal is disabled
  • 8 field lookup limit (which we're nowhere near)

So why is the querying running successfully here, with item requests far beyond even the admin limit?


Are the fields in the lists on your local environment indexed? If they are indexed, then throttling will not occur.

  • The lists are identical, as is the site (they're both created from a template). I seem to remember SPSiteDataQuery ignores indexes entirely when querying, anyway. SPQuery on the other hand will throw a throttling exception on any sized result set if the queried columns are not indexed and the full list is larger than the threshold. – Stu Pegg Jul 5 '13 at 11:41

A colleague of mine did a bit of research as it piqued their curiosity. It seems the cause of the difference is the user account the process is escalated to.

Our customer has followed Microsoft's recommendations and set up an account that does not have administrator permissions. Whereas I was running on a development box with no such restrictions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.