SharePoint-eksport til Excel: hvor oppdateringen faktisk kjører

Eksport til Excel gir tre ulike artefakter avhengig av utrullingen, og feilen hører til nøyaktig én av dem. En nedlastet spørringsfil, en statisk CSV og en koblet tabell som oppdateres er ikke samme resultat, og hver av dem feiler på et ulikt trinn. Å vite hvilket artefakt du har avgjør om neste steg hører til nettverksteamet, identitetsteamet eller listeeieren. Mekanismen nedenfor følger overleveringen fra nettleseren til Excels egen forespørsel.

Hva eksporten faktisk overleverer

På klassiske SharePoint-lister laster Eksporter til Excel ned en liten tekstfil med en URL som innhold, og deretter leser Excel filen og sender sin egen forespørsel etter dataene bak den. Den nedlastede filen er en peker, ikke listen. En CSV-eksport inneholder derimot selve radene og har ingen kobling for oppdatering. En nyere koblet tabell kan legge spørringen direkte inn i arbeidsboken, slik at ingenting havner i mappen Nedlastinger i det hele tatt.

Hver koblet form er enveis. Oppdatering henter gjeldende rader fra listen inn i arbeidsboken, og å redigere tabellen sender ingenting tilbake. Den asymmetrien er viktig for diagnosen, for en arbeidsbok som åpnes med forrige ukes rader har allerede bevist at filen finnes og koblingen ble lagret, men sier ingenting om oppdatering fungerer i dag.

Det første spørsmålet er altså ikke hvorfor eksporten feilet, men hvilket artefakt brukeren forventet. Svaret snevrer undersøkelsen inn til én av tre prosesser.

Tre prosesser, tre ulike identiteter

Nedlastingen i nettleseren bruker nettleserøkten med sine egne informasjonskapsler, proxyoppsett og innloggingsstatus. Excel som åpner filen bruker HTTP-stakken til Office, som vanligvis følger proxyen fra Internett-alternativer per bruker i stedet for WinHTTP-innstillingen for hele maskinen, og som autentiserer seg med hvilken Office-identitet brukeren enn har. En senere oppdatering gjenbruker den lagrede koblingen og kan hente bufrede påloggingsdetaljer fra Windows Legitimasjonsbehandling i stedet for å spørre.

De tre kontekstene kan være uenige på én maskin, og derfor er en nettleser som åpner listen fint og en Excel-oppdatering som returnerer en innloggingsforespørsel et sammenhengende resultat og ikke en motsigelse. Tunnelen endrer rutingen til maskinen for alle tre, men en proxy-autokonfigurasjonsfil kan fortsatt sende Office-forespørsler et annet sted.

Noter hvilken identitet som brukes på hvert trinn før du endrer noen av dem. En retting som brukes på nettleseren kan ikke reparere en forespørsel som Excel gjør under en annen konto.

Les overleveringsfilen før du endrer noe

Den nedlastede filen er ren tekst og vanligvis kort, så les den først. Den navngir verten og endepunktet som Excel kommer til å kalle, og den verten er den som må slås opp og autentiseres fra brukerens maskin, ikke nødvendigvis adressen som er synlig i adressefeltet i nettleseren.

Get-Content "$env:USERPROFILE\Downloads\query.iqy"
Resolve-DnsName team.example.net
netsh winhttp show proxy

Sammenlign verten i filen med nettstedet brukeren tror de eksporterte fra. En omdirigering under eksporten, en gammel nettstedssamling eller en migrert liste kan etterlate en peker til et navn som ikke lenger leverer dataene, og feilen som følger av det ser ut som en nettverksfeil. Hvis navnet slår opp og endepunktet svarer, er de gjenværende kandidatene autentiseringen og selve spørringen.

Ikke bytt ut vertsnavnet med en IP-adresse for å få det til å virke. Det bryter navnekontrollen til sertifikatet og skjuler det egentlige problemet bak en omvei som feiler ved neste sertifikatfornyelse.

Skill navne-, innloggings- og spørringsfeil

Fire utfall dekker nesten hver rapport, og hvert av dem har en annen eier. Et navn som ikke slår opp hører til DNS. En kobling som går i tidsavbrudd hører til ruting eller en proxy. En innloggingsforespørsel eller en 401 hører til identitet. Et svar som kommer men ikke kan tolkes hører til spørringen eller endepunktet som listen nå eksponerer.

Den siste raden er den folk feildiagnostiserer. En oppdatering som fullfører og returnerer feil rader har bevist at hvert nettverks- og identitetslag virker, og det gjenstående spørsmålet er hvilken visning eller hvilket filter spørringen bærer med seg. Å sende den saken til nettverksteamet sløser en dag.

Ta vare på den nøyaktige feilteksten og tidspunktet for den første feilen. Den avgjør hvilken rad i tabellen du er i, og den er det eneste beviset listeeieren kan handle på.

Test oppdateringen på nytt på samme liste

Når det feilende trinnet er identifisert, gjenta handlingen som feilet og ikke en billigere. Oppdater samme liste fra det tiltenkte Excel-miljøet, med den forventede kontoen og den godkjente nettverksveien, og bekreft at radantallet eller en kjent endret verdi faktisk oppdateres. Å åpne en lagret arbeidsbok beviser ingenting om koblingen.

Motstå de brede reparasjonene: å rydde alle lagrede påloggingsdetaljer, kjøre Office forhøyet eller deaktivere en sikkerhetsfunksjon kan endre symptomet uten å reparere trinnet. Hvis autentisering er det feilende laget, be listeeieren bekrefte kontoen og den støttede innloggingsflyten i stedet for å gjette på klienten.

Tilby CSV bare når et frakoblet øyeblikksbilde gjør nytten og den eksporten støttes for miljøet. Å endre utdataformatet endrer arbeidsflyten og forklarer ikke hvorfor den koblede handlingen sluttet å virke.