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 صرف اس وقت پیش کریں جب غیر منسلک اسنیپ شاٹ کام پورا کرے اور وہ ایکسپورٹ ماحول کے لیے معاون ہو۔ آؤٹ پٹ فارمیٹ بدلنا ورک فلو بدلتا ہے اور یہ نہیں بتاتا کہ منسلک عمل کام کرنا کیوں بند ہو گیا۔