SharePoint से Excel में निर्यात: रीफ़्रेश वास्तव में कहाँ चलता है
किसी SharePoint-Excel निर्यात को क्वेरी फ़ाइल, Office के अपने HTTP अनुरोध और सहेजे गए रीफ़्रेश के ज़रिए ट्रेस करें, और पता लगाएँ कि वास्तव में कौन-सा चरण विफल हुआ।
Excel में निर्यात तैनाती के आधार पर तीन अलग-अलग आर्टिफ़ैक्ट बनाता है, और त्रुटि ठीक उनमें से एक की होती है। डाउनलोड की गई क्वेरी फ़ाइल, स्थिर CSV और रीफ़्रेश होने वाली जुड़ी तालिका एक ही परिणाम नहीं हैं, और हर एक अलग चरण पर विफल होती है। यह जानना कि आपके पास कौन-सा आर्टिफ़ैक्ट है, तय करता है कि अगला कदम नेटवर्क टीम, पहचान टीम या सूची के स्वामी का है। नीचे दिया गया तंत्र ब्राउज़र से Excel के अपने अनुरोध तक के हस्तांतरण का अनुसरण करता है।
निर्यात वास्तव में क्या सौंपता है
क्लासिक SharePoint सूचियों में, Excel में निर्यात एक छोटी टेक्स्ट फ़ाइल डाउनलोड करता है जिसका मुख्य भाग एक URL होता है; फिर Excel उस फ़ाइल को पढ़ता है और उसके पीछे के डेटा के लिए अपना अनुरोध भेजता है। डाउनलोड की गई फ़ाइल एक संकेतक है, सूची नहीं। इसके विपरीत CSV निर्यात में पंक्तियाँ स्वयं होती हैं और रीफ़्रेश के लिए कोई कनेक्शन नहीं होता। नई जुड़ी तालिका क्वेरी को सीधे कार्यपुस्तिका में एम्बेड कर सकती है, इसलिए डाउनलोड फ़ोल्डर में कुछ भी नहीं पहुँचता।
हर जुड़ा रूप एकतरफ़ा है। रीफ़्रेश सूची से वर्तमान पंक्तियाँ कार्यपुस्तिका में लाता है, और तालिका संपादित करने से कुछ भी वापस नहीं भेजा जाता। यह असमानता निदान के लिए महत्वपूर्ण है, क्योंकि पिछले सप्ताह की पंक्तियों के साथ खुलने वाली कार्यपुस्तिका पहले ही सिद्ध कर चुकी है कि फ़ाइल मौजूद है और कनेक्शन सहेजा गया था, लेकिन यह नहीं बताती कि रीफ़्रेश आज काम करता है या नहीं।
इसलिए पहला प्रश्न यह नहीं है कि निर्यात क्यों विफल हुआ, बल्कि यह है कि उपयोगकर्ता किस आर्टिफ़ैक्ट की अपेक्षा कर रहा था। उत्तर जाँच को तीन प्रक्रियाओं में से एक तक सीमित करता है।
तीन प्रक्रियाएँ, तीन अलग पहचानें
ब्राउज़र में डाउनलोड ब्राउज़र सत्र का उपयोग करता है, अपनी कुकीज़, प्रॉक्सी कॉन्फ़िगरेशन और साइन-इन स्थिति के साथ। फ़ाइल खोलने वाला 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 केवल तब प्रस्तावित करें जब डिस्कनेक्टेड स्नैपशॉट कार्य को संतुष्ट करे और वह निर्यात वातावरण के लिए समर्थित हो। आउटपुट प्रारूप बदलने से कार्यप्रवाह बदलता है और यह स्पष्ट नहीं करता कि जुड़ा संचालन क्यों काम करना बंद कर गया।