Visningsgrænsen på 5.000 elementer i SharePoint

Visningsgrænsen (List View Threshold) er ikke en grænse for, hvor mange elementer en liste kan have. En liste eller et bibliotek i SharePoint Online kan have 30 millioner (Microsoft). Grænsen gælder den enkelte forespørgsel: en visning, et filter eller en sortering, der skal gennemgå mere end 5.000 elementer i databasen for at give sit svar, bliver afvist.

I SharePoint Online er grænsen fast: “the LVT limit can’t be changed” (Microsoft). I SharePoint Server sætter farmadministratoren den pr. webprogram under Resource Throttling i Central Administration, og der kan sættes et dagligt tidsvindue, hvor den er hævet. Microsoft skriver også, at det faktiske tal ikke altid er præcis 5.000.

Det, der rammer grænsen#

• En visning uden filter, eller med et filter på en kolonne uden indeks, på en liste med flere end 5.000 elementer.
• Et filter med OR. Microsofts eksempel er “size = large OR color = red”, som skal gennemgå hele listen (Microsoft).
• Sortering på person-, opslags- og managed metadata-kolonner. Tekst, tal og datoer går an som første sortering.
• Gruppering og totaler i visningen.
• Tolv eller flere person-, opslags- og managed metadata-kolonner i samme visning (Microsoft).
• På en stor liste også ændringer af selve listen: indeks, sortering i visningens definition og beregnede kolonner, der tilføjes, ændres eller slettes.

Elementer i papirkurven tæller med.

Indeks#

Et indeks på en kolonne gør, at et filter på kolonnen kan finde elementerne uden at gennemgå resten af listen. En liste kan have indeks på op til 20 kolonner (Microsoft). Det sættes under listeindstillingerne → Indexed columns.

To regler for visningen (Microsoft):

• Den første kolonne i filteret skal have indeks. Visningen bruger kun den første kolonnes indeks. De andre kolonner i filteret bruger ikke deres, selv om de har et.
• Den første kolonne skal skære listen ned under 5.000. Et filter på Status = Åben hjælper ikke, hvis 8.000 elementer er åbne.

I SharePoint Online opretter SharePoint selv indeks, når en gemt visning sorterer eller filtrerer på en kolonne, og når der sorteres i den moderne visning. Det sidste sker med det samme på lister under 20.000 elementer; på større lister bygges indekset i baggrunden, og siden med indeks viser “Indexing in progress” (Microsoft).

Om et indeks kan tilføjes i hånden på en liste med over 20.000 elementer, er Microsoft uenig med sig selv om. Supportartiklen om indeks siger, at det i SharePoint Online kan gøres “to a list of any size”, mens fejlsøgningssiden siger, at “The list limit to add or remove an indexed column is 20,000 items” (Microsoft). Det sikre er at sætte indeks på de kolonner, der skal filtreres på, den dag listen oprettes. Det er også rådet i SharePoint-liste eller Dataverse.

Et indeks på en opslagskolonne hjælper ikke mod grænsen.

Mapper#

En visning af én mappe er mindst lige så hurtig som et filter på en kolonne med indeks, så længe mappen ikke har flere end 5.000 elementer. Mapper hjælper altså, når indholdet naturligt kan deles, fx pr. år, og ingen mappe bliver for stor. En mappe må gerne have flere end 5.000, men så er den tilbage ved filtrene (Microsoft).

Store lister fra kode#

Grænsen gælder også det, der henter elementer gennem API’erne. Løsningen er den samme overalt: hent i sider, og filtrér kun på kolonner med indeks.

PnP PowerShell. Get-PnPListItem -List "<liste>" -PageSize 1000 henter side for side (PnP). Med -Query gælder -PageSize ikke; så skal CAML-forespørgslen selv have <RowLimit Paged="TRUE">, og feltet i <Where> skal have indeks. Get-SPWeb og resten af SP-kommandoerne findes kun i SharePoint Server og virker ikke mod SharePoint Online.

REST. $skip virker ikke på listeelementer: “The $skip query option does not work with queries for SharePoint list items” (Microsoft). Uden $top kommer der 100. Næste side hentes med den adresse, svaret selv giver i __next (eller odata.nextLink), og den ser sådan ud:

/_api/web/lists/getbytitle('<liste>')/items?$top=1000&$skiptoken=Paged=TRUE%26p_ID=1000

p_ID er id’et på det sidste element i den forrige side. Den højeste $top for listeelementer har jeg ikke fundet dokumenteret.

Power Automate. Get items henter 100 elementer, hvis Top Count ikke er sat, og Top Count kan højst være 5.000 (Microsoft). Connectorens reference siger ellers “default = all” (Microsoft), men vejledningen siger 100, og det gør noten om at slette listeelementer også. Flere hentes med Pagination i handlingens indstillinger og en tærskel. Den kan højst være 5.000 med licensernes laveste profil (Microsoft 365-planerne) og 100.000 med de andre (Microsoft). En Filter Query uden Pagination ser kun på de første 5.000 elementer, så et flow kan få nul elementer tilbage, selv om der findes nogen længere nede i listen.

Min metode#

Store lister hentes side for side og filtreres på kolonner med indeks, og det står i noterne, der gør det:

• Eksportér en SharePoint-liste til CSV med PowerShell: -PageSize og CAML med RowLimit Paged på et felt med indeks.
• Træk versionshistorikken ud af et listeelement med PowerShell: -PageSize 500 i stedet for alle elementer i ét kald.
• Find kopier og gammelt indhold før en migrering: -PageSize 2000 på store biblioteker.
• Slet listeelementer uden om papirkurven med Power Automate: Top Count, Pagination og et filter på en kolonne med indeks.

Når listen er det forkerte sted#

Hvis appen eller processen skal tælle, gruppere og filtrere på kryds og tværs af mange tusinde rækker, er grænsen et tegn på, at data ikke hører til i en liste. Det er ét af de fire spørgsmål i SharePoint-liste eller Dataverse. At dele en liste i flere lister efter kategori løser grænsen, men ikke en visning eller et flow, der skal se det hele på én gang.

Det der driller#

• Metadatanavigation og nøglefiltre er kun beskrevet for SharePoint Server 2016 og 2019 (Microsoft). Hvordan det virker i SharePoint Online i dag, har jeg ikke fundet dokumenteret, så det er ikke noget at bygge på.
• Export to Excel stopper ved 5.000 elementer.
• Papirkurven tæller med. En liste med 4.000 elementer og 2.000 slettede kan ramme grænsen.
• Et indeks i PowerShell. Feltets egenskab hedder Indexed i CSOM, og Set-PnPField -List "<liste>" -Identity "<kolonne>" -Values @{Indexed=$true} burde sætte det, men PnP viser ikke et eksempel. Ikke kørt.