SharePoint-ից Excel արտահանում. որտեղ է իրականում կատարվում թարմացումը
Հետևեք SharePoint-Excel արտահանմանը հարցման ֆայլի, Office-ի սեփական HTTP հարցման և պահված թարմացման միջոցով և պարզեք, թե որ փուլն է իրականում ձախողվել։
Excel արտահանումը կախված տեղակայումից ստեղծում է երեք տարբեր արտեֆակտ, և սխալը պատկանում է դրանցից ուղիղ մեկին։ Ներբեռնված հարցման ֆայլը, ստատիկ CSV-ն և թարմացվող կապակցված աղյուսակը նույն արդյունքը չեն, և դրանցից յուրաքանչյուրը ձախողվում է տարբեր փուլում։ Իմանալը, թե որ արտեֆակտն ունեք, որոշում է՝ հաջորդ քայլը ցանցային թիմի՞ն է, ինքնության թիմի՞ն, թե՞ ցանկի սեփականատիրոջը։ Ստորև նկարագրված մեխանիզմը հետևում է բրաուզերից Excel-ի սեփական հարցմանը հանձնմանը։
Ինչ է իրականում հանձնում արտահանումը
Դասական SharePoint ցանկերում Excel արտահանելը ներբեռնում է փոքր տեքստային ֆայլ, որի մարմինը URL է, ապա Excel-ը կարդում է այդ ֆայլը և ուղարկում իր սեփական հարցումը դրա հետևում գտնվող տվյալների համար։ Ներբեռնված ֆայլը ցուցիչ է, ոչ թե ցանկը։ CSV արտահանումը, ընդհակառակը, պարունակում է հենց տողերը և թարմացման կապ չունի։ Ավելի նոր կապակցված աղյուսակը կարող է հարցումը ներդնել անմիջապես աշխատանքային գրքում, այնպես որ «Ներբեռնումներ» պանակում ընդհանրապես ոչինչ չի հայտնվում։
Յուրաքանչյուր կապակցված ձև միակողմանի է։ Թարմացումը ցանկից ընթացիկ տողերը ձգում է աշխատանքային գիրք, իսկ աղյուսակը խմբագրելը ոչինչ հետ չի ուղարկում։ Այս ասիմետրիան կարևոր է ախտորոշման համար, որովհետև անցյալ շաբաթվա տողերով բացվող աշխատանքային գիրքն արդեն ապացուցել է, որ ֆայլը գոյություն ունի և կապը պահվել է, բայց ոչինչ չի ասում այն մասին, թե արդյոք թարմացումը այսօր աշխատում է։
Այսպիսով, առաջին հարցը ոչ թե ինչու ձախողվեց արտահանումը, այլ ինչ արտեֆակտ էր սպասում օգտատերը։ Պատասխանը նեղացնում է հետաքննությունը երեք գործընթացներից մեկին։
Երեք գործընթաց, երեք տարբեր ինքնություն
Բրաուզերում ներբեռնումն օգտագործում է բրաուզերի սեսիան իր սեփական cookie-ներով, վստահված սերվերի կարգավորմամբ և մուտքի վիճակով։ Ֆայլը բացող Excel-ը օգտագործում է Office-ի HTTP ստեկը, որը սովորաբար հետևում է Ինտերնետի ընտրանքների վստահված սերվերին ըստ օգտատիրոջ, այլ ոչ թե ամբողջ մեքենայի WinHTTP կարգավորմանը, և նույնականացվում է ցանկացած Office ինքնությամբ, որն ունի օգտատերը։ Ավելի ուշ թարմացումը կրկին օգտագործում է պահված կապը և կարող է քեշավորված հավատարմագրեր վերցնել Windows-ի հավատարմագրերի կառավարիչից՝ հարցնելու փոխարեն։
Այս երեք համատեքստերը կարող են չհամընկնել մեկ մեքենայի վրա, և դրա համար էլ ցանկը անխնդիր բացող բրաուզերը և մուտքի հարցում վերադարձնող Excel թարմացումը համահունչ արդյունք են, ոչ թե հակասություն։ Թունելը փոխում է մեքենայի երթուղավորումը երեքի համար էլ, բայց վստահված սերվերի ավտոմատ կազմաձևման ֆայլը դեռ կարող է Office-ի հարցումներն ուղարկել այլ տեղ։
Գրանցեք յուրաքանչյուր փուլում օգտագործվող ինքնությունը, նախքան դրանցից որևէ մեկը փոխելը։ Բրաուզերի վրա կիրառված ուղղումը չի կարող ուղղել հարցումը, որը Excel-ը կատարում է այլ հաշվով։
Կարդացեք հանձնման ֆայլը, նախքան ինչ-որ բան փոխելը
Ներբեռնված ֆայլը պարզ տեքստ է և սովորաբար կարճ է, ուստի կարդացեք այն առաջինը։ Այն նշում է հոսթը և վերջնակետը, որոնք Excel-ը կկանչի, և հենց այդ հոսթն է, որ պետք է լուծարվի և նույնականացվի օգտատիրոջ մեքենայից, ոչ պարտադիր բրաուզերի հասցեագոտում երևացող հասցեն։
Get-Content "$env:USERPROFILE\Downloads\query.iqy"
Resolve-DnsName team.example.net
netsh winhttp show proxyՀամեմատեք ֆայլի հոսթը այն կայքի հետ, որտեղից օգտատերը կարծում է, թե արտահանել է։ Արտահանման ընթացքում վերահղումը, հին կայքերի հավաքածուն կամ տեղափոխված ցանկը կարող են թողնել ցուցիչ դեպի անուն, որն այլևս չի սպասարկում տվյալները, և դրանից առաջացած սխալը նման է ցանցային խափանման։ Եթե անունը լուծարվում է և վերջնակետը պատասխանում է, մնացած թեկնածուներն են նույնականացումը և հենց հարցումը։
Չփոխարինեք հոսթի անունը IP հասցեով, որպեսզի աշխատի։ Դա խախտում է վկայագրի անվան ստուգումը և թաքցնում է իրական խնդիրը շրջանցող լուծման հետևում, որը ձախողվում է հաջորդ վկայագրի թարմացման ժամանակ։
Առանձնացրեք անվան, մուտքի և հարցման խափանումները
Չորս արդյունք ընդգրկում են գրեթե բոլոր դիմումները, և յուրաքանչյուրն ունի տարբեր սեփականատեր։ Անուն, որը չի լուծարվում, պատկանում է DNS-ին։ Կապ, որը ժամկետանց է դառնում, պատկանում է երթուղավորմանը կամ վստահված սերվերին։ Մուտքի հարցումը կամ 401-ը պատկանում են ինքնությանը։ Պատասխանը, որը գալիս է, բայց հնարավոր չէ վերլուծել, պատկանում է հարցմանը կամ այն վերջնակետին, որը ցանկն այժմ ներկայացնում է։
| 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 |
Վերջին տողն այն է, որը մարդիկ սխալ են ախտորոշում։ Ավարտվող և սխալ տողեր վերադարձնող թարմացումն արդեն ապացուցել է, որ յուրաքանչյուր ցանցային և ինքնության շերտ աշխատում է, և մնացած հարցն այն է, թե որ տեսքը կամ որ զտիչն է կրում հարցումը։ Այդ տոմսը ցանցային թիմ ուղարկելը մեկ օր է վատնում։
Պահեք սխալի ճշգրիտ տեքստը և առաջին խափանման ժամը։ Այն որոշում է, թե աղյուսակի որ տողում եք գտնվում, և դա միակ ապացույցն է, որի վրա ցանկի սեփականատերը կարող է գործել։
Կրկին ստուգեք թարմացումը նույն ցանկում
Ձախողվող փուլը բացահայտելուց հետո կրկնեք ձախողված գործողությունը, այլ ոչ ավելի էժանը։ Թարմացրեք նույն ցանկը նախատեսված Excel միջավայրից՝ սպասվող հաշվով և հաստատված ցանցային ուղով, և հաստատեք, որ տողերի քանակը կամ հայտնի փոփոխված արժեքը իսկապես թարմացվում է։ Պահված աշխատանքային գիրք բացելը ոչինչ չի ապացուցում կապի մասին։
Դիմացե՛ք լայն վերանորոգումներին. բոլոր պահված հավատարմագրերը ջնջելը, Office-ը բարձրացված իրավունքներով գործարկելը կամ անվտանգության գործառույթն անջատելը կարող է փոխել ախտանիշը՝ չուղղելով փուլը։ Եթե նույնականացումը ձախողվող շերտն է, խնդրեք ցանկի սեփականատիրոջը հաստատել հաշիվը և աջակցվող մուտքի հոսքը՝ հաճախորդի վրա գուշակելու փոխարեն։
Առաջարկեք CSV միայն այն ժամանակ, երբ անջատված պատկերը բավարարում է առաջադրանքը և այդ արտահանումը աջակցվում է միջավայրում։ Ելքի ձևաչափի փոփոխությունը փոխում է աշխատանքային հոսքը և չի բացատրում, թե ինչու է կապակցված գործողությունը դադարել աշխատել։