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 फक्त तेव्हाच सुचवा जेव्हा डिस्कनेक्ट केलेला स्नॅपशॉट कार्य पूर्ण करतो आणि ते निर्यात वातावरणासाठी समर्थित आहे। आउटपुट स्वरूप बदलल्याने कार्यप्रवाह बदलतो आणि जोडलेले कार्य का थांबले हे स्पष्ट करत नाही।