Az Excelbe exportálás a telepítéstől függően három különböző artefaktumot állít elő, és a hiba pontosan egyhez tartozik közülük. A letöltött lekérdezésfájl, a statikus CSV és a frissülő kapcsolt tábla nem ugyanaz az eredmény, és mindegyik más szakaszban hibázik. Ha tudja, melyik artefaktuma van, eldöntheti, hogy a következő lépés a hálózati csapaté, az identitáscsapaté vagy a lista tulajdonosáé. Az alábbi mechanizmus a böngészőtől az Excel saját kéréséig követi az átadást.

Mit ad át valójában az export

Klasszikus SharePoint-listákon az Exportálás Excelbe letölt egy kis szöveges fájlt, amelynek törzse egy URL, majd az Excel beolvassa ezt a fájlt, és saját kérést indít a mögötte lévő adatokért. A letöltött fájl mutató, nem a lista. A CSV-export ezzel szemben magukat a sorokat tartalmazza, és nincs frissítési kapcsolata. Az újabb kapcsolt tábla beágyazhatja a lekérdezést közvetlenül a munkafüzetbe, így semmi sem kerül a Letöltések mappába.

Minden kapcsolt forma egyirányú. A frissítés az aktuális sorokat hozza a listából a munkafüzetbe, a tábla szerkesztése pedig semmit nem küld vissza. Ez az aszimmetria a diagnózis szempontjából fontos, mert a múlt heti sorokkal megnyíló munkafüzet már bizonyította, hogy a fájl létezik és a kapcsolat mentésre került, viszont semmit nem mond arról, hogy a frissítés ma működik-e.

Tehát az első kérdés nem az, miért hibázott az export, hanem az, milyen artefaktumot várt a felhasználó. A válasz a vizsgálatot három folyamat egyikére szűkíti.

Három folyamat, három különböző identitás

A böngészőben történő letöltés a böngésző munkamenetét használja, saját sütikkel, proxybeállítással és bejelentkezési állapottal. Az Excel a fájl megnyitásakor az Office HTTP-veremét használja, amely általában a felhasználónkénti Internetbeállítások proxyját követi a gép szintű WinHTTP-beállítás helyett, és a felhasználó bármely Office-identitásával hitelesít. Egy későbbi frissítés újrahasználja a mentett kapcsolatot, és a Windows Hitelesítőadat-kezelőből származó gyorsítótárazott hitelesítő adatokat vehet igénybe kérdezés helyett.

Ez a három kontextus egyetlen gépen is ellentmondhat egymásnak, ezért az a böngésző, amely gond nélkül megnyitja a listát, és az az Excel-frissítés, amely bejelentkezési kérést ad vissza, összeegyeztethető eredmény, nem pedig ellentmondás. Az alagút mindhárom esetében módosítja a gép útválasztását, de egy proxy automatikus konfigurációs fájl továbbra is máshová küldheti az Office kéréseit.

Jegyezze fel az egyes szakaszokban használt identitást, mielőtt bármelyiket megváltoztatja. A böngészőn alkalmazott javítás nem tudja helyrehozni azt a kérést, amelyet az Excel más fiókkal indít.

Olvassa el az átadási fájlt, mielőtt bármit megváltoztat

A letöltött fájl egyszerű szöveg, és általában rövid, ezért először olvassa el. Megnevezi a gazdagépet és azt a végpontot, amelyet az Excel hívni fog, és ez a gazdagép az, amelyet a felhasználó gépéről fel kell oldani és hitelesíteni kell, nem feltétlenül a böngésző címsorában látható cím.

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

Hasonlítsa össze a fájlban szereplő gazdagépet azzal a webhellyel, ahonnan a felhasználó úgy gondolja, hogy exportált. Az exportálás közbeni átirányítás, egy régi webhelygyűjtemény vagy egy áttelepített lista olyan mutatót hagyhat hátra, amely már nem szolgálja ki az adatokat, és az ebből eredő hiba hálózati hibának tűnik. Ha a név feloldódik és a végpont válaszol, a fennmaradó jelöltek a hitelesítés és maga a lekérdezés.

Ne cserélje le a gazdagépnevet IP-címre, hogy működjön. Ez megtöri a tanúsítvány névellenőrzését, és elrejti a valódi problémát egy olyan kerülő megoldás mögé, amely a következő tanúsítvány-megújításnál elbukik.

Válassza szét a név-, bejelentkezési és lekérdezési hibákat

Négy kimenet szinte minden bejelentést lefed, és mindegyiknek más a tulajdonosa. A fel nem oldható név a DNS-hez tartozik. Az időtúllépésbe futó kapcsolat az útválasztáshoz vagy egy proxyhoz tartozik. A bejelentkezési kérés vagy a 401 az identitáshoz tartozik. A megérkező, de feldolgozhatatlan válasz a lekérdezéshez vagy ahhoz a végponthoz tartozik, amelyet a lista most közzétesz.

What the user seesStage that failed
Data source could not be foundName resolution or the pointer in the file
Repeated sign-in promptOffice identity or cached credential
Timeout while refreshingRoute, proxy or the VPN path
Refresh succeeds, rows look wrongQuery scope or list view, not connectivity

Az utolsó sor az, amelyet az emberek rosszul diagnosztizálnak. Az a frissítés, amely befejeződik és rossz sorokat ad vissza, már bizonyította, hogy minden hálózati és identitási réteg működik, és a fennmaradó kérdés az, hogy melyik nézetet vagy szűrőt hordozza a lekérdezés. Ha ezt a jegyet a hálózati csapatnak küldi, az egy napot pazarol el.

Őrizze meg a pontos hibaüzenetet és az első hiba időpontját. Ez dönti el, hogy a tábla melyik sorában van, és ez az egyetlen bizonyíték, amelyre a lista tulajdonosa támaszkodhat.

Tesztelje újra a frissítést ugyanazon a listán

Miután a hibázó szakaszt azonosította, ismételje meg a sikertelen műveletet, és ne egy olcsóbbat. Frissítse ugyanazt a listát a tervezett Excel-környezetből, a várt fiókkal és a jóváhagyott hálózati útvonalon, és erősítse meg, hogy a sorszám vagy egy ismert megváltozott érték valóban frissül. Egy mentett munkafüzet megnyitása semmit nem bizonyít a kapcsolatról.

Álljon ellen a széles körű javításoknak: az összes mentett hitelesítő adat törlése, az Office emelt szintű futtatása vagy egy biztonsági funkció kikapcsolása megváltoztathatja a tünetet anélkül, hogy javítaná a szakaszt. Ha a hitelesítés a hibázó réteg, kérje meg a lista tulajdonosát, hogy erősítse meg a fiókot és a támogatott bejelentkezési folyamatot, ahelyett hogy az ügyfélen találgatna.

Csak akkor kínáljon CSV-t, ha egy leválasztott pillanatkép kielégíti a feladatot, és az az export támogatott a környezetben. A kimeneti formátum megváltoztatása megváltoztatja a munkafolyamatot, és nem magyarázza meg, miért állt le a kapcsolt művelet.

Kapcsolódó cikkek