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 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

છેલ્લી પંક્તિ તે જ છે જેનું લોકો ખોટું નિદાન કરે છે. પૂર્ણ થઈને ખોટી પંક્તિઓ પાછી આપતું રિફ્રેશ પહેલેથી જ સાબિત કરી ચૂક્યું છે કે દરેક નેટવર્ક અને ઓળખ સ્તર કામ કરે છે, અને બાકીનો પ્રશ્ન એ છે કે ક્વેરી કઈ દૃશ્ય કે કઈ ગાળણી લઈને જાય છે. તે ટિકિટ નેટવર્ક ટીમને મોકલવી એક દિવસ બગાડવો છે.

ભૂલનો ચોક્કસ ટેક્સ્ટ અને પ્રથમ નિષ્ફળતાનો સમય સાચવો. તે જ નક્કી કરે છે કે તમે કોષ્ટકની કઈ પંક્તિમાં છો, અને યાદીનો માલિક જેના પર કાર્યવાહી કરી શકે તે એકમાત્ર પુરાવો આ જ છે.

તે જ યાદી પર રિફ્રેશ ફરી ચકાસો

નિષ્ફળ તબક્કો ઓળખાયા પછી જે ક્રિયા નિષ્ફળ ગઈ તે પુનરાવર્તિત કરો, સસ્તી ક્રિયા નહીં. તે જ યાદીને ઇચ્છિત Excel પર્યાવરણમાંથી, અપેક્ષિત ખાતા અને મંજૂર નેટવર્ક માર્ગ સાથે રિફ્રેશ કરો, અને પુષ્ટિ કરો કે પંક્તિ સંખ્યા કે જાણીતું બદલાયેલું મૂલ્ય ખરેખર અદ્યતન થાય છે. સાચવેલી કાર્યપુસ્તિકા ખોલવી જોડાણ વિશે કંઈ પણ સાબિત કરતી નથી.

વ્યાપક સમારકામોનો પ્રતિકાર કરો: બધા સાચવેલા ક્રેડેન્શિયલ ભૂંસવા, Office ઉન્નત રીતે ચલાવવું કે કોઈ સુરક્ષા સુવિધા નિષ્ક્રિય કરવી તે તબક્કો સુધાર્યા વિના લક્ષણ બદલી શકે છે. જો પ્રમાણીકરણ નિષ્ફળ સ્તર હોય, તો ક્લાયન્ટ પર અનુમાન લગાવવાને બદલે યાદીના માલિકને ખાતું અને સમર્થિત સાઇન-ઇન પ્રવાહની પુષ્ટિ કરવા કહો.

CSV ફક્ત ત્યારે જ સૂચવો જ્યારે ડિસ્કનેક્ટેડ સ્નેપશોટ કાર્યને સંતોષે અને તે નિકાસ પર્યાવરણ માટે સમર્થિત હોય. આઉટપુટ ફોર્મેટ બદલવાથી કાર્યપ્રવાહ બદલાય છે અને જોડાયેલી ક્રિયા કેમ કામ કરવાનું બંધ કર્યું તે સ્પષ્ટ કરતું નથી.

સંબંધિત લેખો