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 მხოლოდ მაშინ, როცა გაწყვეტილი კადრი აკმაყოფილებს დავალებას და ეს ექსპორტი გარემოში მხარდაჭერილია. გამოყვანის ფორმატის შეცვლა ცვლის სამუშაო ნაკადს და არ ხსნის, რატომ შეწყვიტა დაკავშირებულმა ოპერაციამ მუშაობა.