SharePoint-eksporto al Excel: kie la refreŝigo vere ruliĝas
Spuru SharePoint-Excel-eksporton tra la demando-dosiero, la propra HTTP-peto de Office kaj la konservita refreŝigo, kaj trovu kiun etapon fakte malsukcesis.
La eksporto al Excel produktas tri malsamajn artefaktojn laŭ la enkonduko, kaj la eraro apartenas al ekzakte unu el ili. Elŝutita demando-dosiero, statika CSV kaj ligita tabelo, kiu refreŝiĝas, ne estas la sama rezulto, kaj ĉiu el ili malsukcesas en malsama etapo. Scii, kiun artefakton vi havas, decidas ĉu la sekva paŝo apartenas al la reta teamo, la identeca teamo aŭ la posedanto de la listo. La mekanismo malsupre sekvas la transdonon de la retumilo al la propra peto de Excel.
Kion la eksporto fakte transdonas
Ĉe klasikaj SharePoint-listoj, Eksporti al Excel elŝutas malgrandan tekstdosieron, kies korpo estas URL, kaj poste Excel legas tiun dosieron kaj sendas sian propran peton por la datumoj malantaŭ ĝi. La elŝutita dosiero estas montrilo, ne la listo. CSV-eksporto, kontraste, enhavas la vicojn mem kaj havas neniun ligon por refreŝigi. Pli nova ligita tabelo povas enigi la demandon rekte en la laborlibron, tiel ke nenio entute alvenas en la dosierujon Elŝutoj.
Ĉiu ligita formo estas unudirekta. Refreŝigo tiras aktualajn vicojn el la listo en la laborlibron, kaj redakti la tabelon sendas nenion reen. Tiu nesimetrio gravas por diagnozo, ĉar laborlibro, kiu malfermiĝas kun la vicoj de pasinta semajno, jam pruvis, ke la dosiero ekzistas kaj la ligo estis konservita, dum ĝi diras nenion pri tio, ĉu refreŝigo funkcias hodiaŭ.
Do la unua demando ne estas, kial la eksporto malsukcesis, sed kiun artefakton la uzanto atendis. La respondo limigas la esploron al unu el tri procezoj.
Tri procezoj, tri malsamaj identecoj
La elŝuto en la retumilo uzas la retumilan seancon, kun siaj propraj kuketoj, prokura agordo kaj ensaluta stato. Excel malfermanta la dosieron uzas la HTTP-stakon de Office, kiu ĝenerale sekvas la prokuron el la Interretaj opcioj por uzanto anstataŭ la WinHTTP-agordo por la tuta maŝino, kaj kiu aŭtentikigas per kiu ajn Office-identeco, kiun la uzanto havas. Pli posta refreŝigo reuzas la konservitan ligon kaj povas preni kaŝmemorigitajn akreditaĵojn el la Windows-akreditaĵadministrilo anstataŭ demandi.
Tiuj tri kuntekstoj povas malkonsenti sur unu maŝino, kaj tial retumilo, kiu malfermas la liston bone, kaj Excel-refreŝigo, kiu resendas ensalutpeton, estas kohera rezulto kaj ne kontraŭdiro. La tunelo ŝanĝas la vojigon de la maŝino por ĉiuj tri, sed prokura aŭtokonfigura dosiero ankoraŭ povas sendi Office-petojn aliloken.
Notu la identecon uzatan en ĉiu etapo antaŭ ol ŝanĝi iun ajn el ili. Riparo aplikita al la retumilo ne povas ripari peton, kiun Excel faras sub alia konto.
Legu la transdonan dosieron antaŭ ol ŝanĝi ion
La elŝutita dosiero estas simpla teksto kaj kutime mallonga, do legu ĝin unue. Ĝi nomas la gastiganton kaj la finpunkton, kiujn Excel vokos, kaj tiu gastiganto estas tiu, kiu devas esti solvita kaj aŭtentikigita de la maŝino de la uzanto, ne nepre la adreso videbla en la adresbreto de la retumilo.
Get-Content "$env:USERPROFILE\Downloads\query.iqy"
Resolve-DnsName team.example.net
netsh winhttp show proxy
Komparu la gastiganton en la dosiero kun la retejo, de kiu la uzanto opinias, ke ĝi eksportis. Alidirektado dum la eksporto, malnova retejo-kolekto aŭ migrita listo povas lasi montrilon al nomo, kiu ne plu servas la datumojn, kaj la rezulta eraro aspektas kiel reta fiasko. Se la nomo solviĝas kaj la finpunkto respondas, la restantaj kandidatoj estas la aŭtentikigo kaj la demando mem.
Ne anstataŭigu la gastigantan nomon per IP-adreso por igi ĝin funkcii. Tio rompas la nomkontrolon de la atestilo kaj kaŝas la realan problemon malantaŭ provizora solvo, kiu malsukcesas ĉe la sekva atestila renovigo.
Apartigu nomajn, ensalutajn kaj demandajn erarojn
Kvar rezultoj kovras preskaŭ ĉiun raporton, kaj ĉiu havas alian posedanton. Nomo, kiu ne solviĝas, apartenas al DNS. Ligo, kiu tempolimas, apartenas al vojigo aŭ al prokuro. Ensalutpeto aŭ 401 apartenas al identeco. Respondo, kiu alvenas sed ne povas esti analizita, apartenas al la demando aŭ al la finpunkto, kiun la listo nun elmontras.
| What the user sees | Stage that failed |
|---|---|
| Data source could not be found | Name resolution or the pointer in the file |
| Repeated sign-in prompt | Office identity or cached credential |
| Timeout while refreshing | Route, proxy or the VPN path |
| Refresh succeeds, rows look wrong | Query scope or list view, not connectivity |
La lasta vico estas tiu, kiun homoj fuŝdiagnozas. Refreŝigo, kiu kompletiĝas kaj resendas la malĝustajn vicojn, jam pruvis, ke ĉiu reta kaj identeca tavolo funkcias, kaj la restanta demando estas, kiun vidon aŭ kiun filtrilon la demando portas. Sendi tiun bileton al la reta teamo malŝparas tagon.
Konservu la ekzaktan erartekston kaj la tempon de la unua fiasko. Ĝi decidas, en kiu vico de la tabelo vi estas, kaj ĝi estas la sola pruvo, sur kiu la posedanto de la listo povas agi.
Retestu la refreŝigon sur la sama listo
Post kiam la malsukcesa etapo estas identigita, ripetu la operacion, kiu malsukcesis, kaj ne pli malmultekostan. Refreŝigu la saman liston el la intencita Excel-medio, kun la atendata konto kaj la aprobita reta vojo, kaj konfirmu, ke la vicnombro aŭ konata ŝanĝita valoro vere ĝisdatiĝas. Malfermi konservitan laborlibron pruvas nenion pri la ligo.
Rezistu la larĝajn riparojn: viŝi ĉiujn konservitajn akreditaĵojn, ruli Office altigite aŭ malŝalti sekurecan funkcion povas ŝanĝi la simptomon sen ripari la etapon. Se aŭtentikigo estas la malsukcesa tavolo, petu la posedanton de la listo konfirmi la konton kaj la subtenatan ensalutan fluon anstataŭ diveni ĉe la kliento.
Ofertu CSV nur kiam malkonektita momenta bildo kontentigas la taskon kaj tiu eksporto estas subtenata por la medio. Ŝanĝi la eligan formaton ŝanĝas la laborfluon kaj ne klarigas, kial la ligita operacio ĉesis funkcii.