Export SharePoint în Excel: unde rulează de fapt reîmprospătarea

Exportul în Excel produce trei artefacte diferite în funcție de implementare, iar defecțiunea aparține exact unuia dintre ele. Un fișier de interogare descărcat, un CSV static și un tabel conectat care se reîmprospătează nu sunt același rezultat, iar fiecare eșuează într-o altă etapă. Faptul de a ști ce artefact aveți decide dacă pasul următor aparține echipei de rețea, echipei de identitate sau proprietarului listei. Mecanismul de mai jos urmărește predarea de la browser la cererea proprie a Excel.

Ce predă de fapt exportul

În listele SharePoint clasice, Export în Excel descarcă un fișier text mic al cărui corp este un URL, apoi Excel citește acel fișier și emite propria cerere pentru datele din spatele lui. Fișierul descărcat este un indicator, nu lista. Un export CSV, dimpotrivă, conține rândurile înseși și nu are nicio conexiune pentru reîmprospătare. Un tabel conectat mai nou poate încorpora interogarea direct în registru, astfel încât nimic nu ajunge în folderul Descărcări.

Fiecare formă conectată este unidirecțională. Reîmprospătarea aduce rândurile curente din listă în registru, iar editarea tabelului nu trimite nimic înapoi. Această asimetrie contează pentru diagnostic, pentru că un registru care se deschide cu rândurile de săptămâna trecută a dovedit deja că fișierul există și că conexiunea a fost salvată, fără să spună nimic despre dacă reîmprospătarea funcționează astăzi.

Așadar prima întrebare nu este de ce a eșuat exportul, ci ce artefact aștepta utilizatorul. Răspunsul restrânge investigația la unul dintre trei procese.

Trei procese, trei identități diferite

Descărcarea din browser folosește sesiunea browserului, cu propriile cookie-uri, configurația de proxy și starea de conectare. Excel, când deschide fișierul, folosește stiva HTTP a Office, care în general urmează proxy-ul din Opțiunile Internet pe utilizator în loc de setarea WinHTTP la nivel de mașină și care se autentifică cu orice identitate Office are utilizatorul. O reîmprospătare ulterioară reutilizează conexiunea salvată și poate prelua acreditări din cache din Managerul de acreditări Windows în loc să întrebe.

Acele trei contexte pot fi în dezacord pe o singură mașină, și de aceea un browser care deschide lista fără probleme și o reîmprospătare Excel care returnează o cerere de autentificare sunt un rezultat coerent, nu o contradicție. Tunelul schimbă rutarea mașinii pentru toate trei, dar un fișier de configurare automată a proxy-ului poate trimite în continuare cererile Office în altă parte.

Notați identitatea folosită la fiecare etapă înainte de a schimba vreuna dintre ele. O corecție aplicată browserului nu poate repara o cerere pe care Excel o face sub alt cont.

Citiți fișierul de predare înainte de a schimba ceva

Fișierul descărcat este text simplu și de obicei scurt, așa că citiți-l mai întâi. El numește gazda și punctul final pe care le va apela Excel, iar acea gazdă este cea care trebuie rezolvată și autentificată de pe mașina utilizatorului, nu neapărat adresa vizibilă în bara de adrese a browserului.

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

Comparați gazda din fișier cu site-ul de pe care utilizatorul crede că a exportat. O redirecționare în timpul exportului, o colecție de site-uri veche sau o listă migrată pot lăsa un indicator către un nume care nu mai servește datele, iar eroarea rezultată arată ca o defecțiune de rețea. Dacă numele se rezolvă și punctul final răspunde, candidații rămași sunt autentificarea și interogarea în sine.

Nu înlocuiți numele gazdei cu o adresă IP pentru a-l face să funcționeze. Asta rupe verificarea numelui certificatului și ascunde problema reală în spatele unei soluții ocolitoare care eșuează la următoarea reînnoire a certificatului.

Separați defecțiunile de nume, de conectare și de interogare

Patru rezultate acoperă aproape fiecare raport, iar fiecare are alt proprietar. Un nume care nu se rezolvă aparține DNS. O conexiune care expiră aparține rutării sau unui proxy. O cerere de conectare sau un 401 aparțin identității. Un răspuns care sosește dar nu poate fi analizat aparține interogării sau punctului final pe care lista îl expune acum.

Ultimul rând este cel pe care oamenii îl diagnostichează greșit. O reîmprospătare care se finalizează și returnează rândurile greșite a dovedit deja că fiecare strat de rețea și de identitate funcționează, iar întrebarea rămasă este ce vizualizare sau ce filtru poartă interogarea. Trimiterea acelui tichet la echipa de rețea irosește o zi.

Păstrați textul exact al erorii și ora primei defecțiuni. El decide în ce rând al tabelului vă aflați și este singura dovadă pe care proprietarul listei poate acționa.

Retestați reîmprospătarea pe aceeași listă

Odată identificată etapa care eșuează, repetați operațiunea care a eșuat, nu una mai ieftină. Reîmprospătați aceeași listă din mediul Excel prevăzut, cu contul așteptat și calea de rețea aprobată, și confirmați că numărul de rânduri sau o valoare modificată cunoscută se actualizează într-adevăr. Deschiderea unui registru salvat nu dovedește nimic despre conexiune.

Rezistați reparațiilor ample: ștergerea tuturor acreditărilor salvate, rularea Office cu privilegii ridicate sau dezactivarea unei funcții de securitate poate schimba simptomul fără a repara etapa. Dacă autentificarea este stratul care eșuează, cereți proprietarului listei să confirme contul și fluxul de conectare acceptat în loc să ghiciți la client.

Oferiți CSV doar când un instantaneu deconectat satisface sarcina și acel export este acceptat pentru mediu. Schimbarea formatului de ieșire schimbă fluxul de lucru și nu explică de ce operațiunea conectată a încetat să funcționeze.