"القيمة لا تقع ضمن النطاق المتوقع" لحقل البحث وعلاقته بتقييد الموارد لتطبيق الويب

Question

كنت أقوم بالاستعلام عن قائمة تحتوي على العديد من الأعمدة، بعضها عبارة عن عمليات بحث.كان استعلامي هو إرجاع SPListItem بناءً على معرف واحد.الآن، عندما أرغب في ربط قيمة حقل البحث من SPListItem إلى القائمة المنسدلة أو حقل النص، واجهت موقفًا مثيرًا للاهتمام.

لقد استخدمت الكود أدناه للحصول على قيمة البحث:

SPFieldLookupValue fieldLookupValue1 = new SPFieldLookupValue(ListItem["LookupField"].ToString());

if (fieldLookupValue1 != null)
   Textbox.text = fieldLookupValue1.LookupValue;

ما سبق كان يعمل بشكل جيد عند تسجيل الدخول كحساب النظام.ولكنه يلقي خطأ "القيمة لا تقع ضمن النطاق المتوقع" عند تسجيل الدخول باستخدام مستخدم لديه حق الوصول للقراءة أو أعلى.الأمر المثير للاهتمام هو أنه بعد زيادة القيمة في "عتبة البحث عن طريقة عرض القائمة" ضمن التحكم في الموارد لتطبيق الويب في الإدارة المركزية، تم حل هذه المشكلة من تلقاء نفسها.

هل يمكن لأحد أن يشرح ما يحدث في الخلف؟ما هي المفاضلة لزيادة القيم في ظل تقييد الموارد؟

Answer 1

وكما أشار كاميرون، فإن السبب هو الأداء.حصل المسؤولون على إذن للاستعلام فوق الأعمدة الثمانية الافتراضية، بينما لا يفعل ذلك المستخدم العادي.

تنص Microsoft على ما يلي على موقعها حول أداء القائمة.انظر الجزء أعمدة البحث وطرق عرض القائمة في المقالة.هناك بعض الرسوم البيانية الجيدة التي توضح ما يحدث مع أداء SQL أيضًا.

يؤدي كل عمود بحث في طريقة عرض القائمة إلى ربطه بجدول آخر.يزيد كل عمود بحث إضافي في طريقة العرض من تعقيد استفسارات التنقل في البيانات الوصفية وقائمة العرض.بالإضافة إلى أعمدة البحث القياسية ، فإن البيانات الوصفية المدارة ذات القيمة الواحدة ، والبيانات الوصفية المدارة متعددة القيمة ، والأشخاص ذوي القيمة الواحدة والأعمدة الجماعية ، وأشخاص متعددي القيمة والأعمدة الجماعية يعتبرون أعمدة بحث.لا تتسبب إضافة أعمدة البحث إلى عرض إلى انخفاض تدريجي أو خطي في الأداء ، بل إن الأداء مستقر إلى حد ما حتى بعد ثمانية أعمدة عندما يتحلل بسرعة.

تصميم قوائم كبيرة وتعظيم أداء القائمة