SharePoint 2013 had a default List View Threshold that used the number 5,000 for a lot of limits. SharePoint 2016 has made a few changes to the List View Threshold to give us a little more flexibility. If you take a look at the TechNet article “Software boundaries and limits for SharePoint Server 2016” you will find that the old 5,000 limit is still there for normal list activity, but they have made a few changes for Site Owner maintenance activities.
These include:
- When adding or removing a column index, the threshold is 20,000 by default.
- When deleting a list or folder, the threshold is 100,000 by default.
- When renaming a folder within the same library, the threshold is 100,000 by default.
Note that these limits are for Team Members, Site Owners and Site Collection Administrators. Server administrators can exceed these limits and everyone can during “happy hour!” (Officially, the “Daily Time Window for Large Queries” limit set by the SharePoint Server administrators.)
As I am working on a new course, “Microsoft SharePoint Server Content Management for SharePoint 2013 and 2016”, I have to both test these limits and create screen captures for classroom demos. I ran into two interesting discoveries:
- I could rename folders when there were more than 100,000 items. So this one must be for when there are up to 100,000 folders at the same level.
- I could NOT delete a list with 100,000 items. Or, 99,999 items.
The delete issue was a bit more interesting… I started deleting items, even emptied the Recycle Bin after each delete, but still could not delete the list… until I hit 99,993 items. Weird huh? That number is not even a magic number (a power of 2). I guess there must seven hidden, for SharePoint’s use only, items in that large list. Who knows…
I could not delete the following list until the item count was below 99,994.
99,993… now I can delete it.
Now… should I go an tie up the bandwidth to create a 100,000 item list in SharePoint Online to test there?
Of course!
.
5 comments:
Isn't this caused by the 4 default files a list creates for the views, 1 folder for attachments and 1 folder for every contenttype that you attach to a list? These aren't counted in the UI, but i'm sure they are counted internally as they are just normal items. As a test i created a standard list and attached 1 contenttype. The number of hidden files came to 6 already (or 7 is the root folder is also counted)
If you use the API or Designer you can see these hidden files.
Jeffery,
I think you nailed it! If there is a hidden root folder object, then there's the missing seven items. I added some test files to the folder path using Designer and the number of items that impacted the ability to delete the list changed based on that pattern. As this was a list and not a library I did not expect anything other than the list items to be counted.
The seven hidden items (99,993 + these = 100,000 items):
Attachments (folder)
Item (folder)
AllItems.aspx
DispForm.aspx
EditForm.aspx
NewForm.aspx
(unknown? default root folder?)
What's interesting is that this seems to impact the count at the 100,000 item level. These extra files seem to be ignored at the 5,000 LVTs.
Mike
It's crazy we have to get the number of items below 100k just to DELETE a list!
M.
sympmarc,
Yup! But, you can delete a site or a site collection with a list with more than 100,000 items no problem. (I do need to retest this.)
Mike
I second what Marc says. It seems astonishing that MS says a list can hold 30,000,000 items, without giving a warning in the same breath that once it is over 100,000 items, its functionality is severely restricted. And in Office 365, there is not any chance of a daily time window for large queries.
I once had a SharePoint 2010 list of 1.4 million items on which the user wanted an additional report, which required one more column to be indexed, but the (outsourced) IT team would not hear of indexing it for me, nor did they offer a daily time window for large queries. Their suggestion was that I reduce the list to under 5,001 items, then index the column myself.
Someone internal eventually decided we should have a daily time window for large queries, and I was able to index the column. Given IT's attitude, I was sure it would take hours to index. Nope, it took less than 2 minutes!!
At least in SharePoint 2010 we could work with 50,000 items at a time in the datasheet view. Unfortunately, they have taken that away from us as well.
Post a Comment