مشكلة في استدعاء الإجراء المخزن من إجراء مخزن آخر عبر ASP الكلاسيكي

Question

لدينا تطبيق ASP كلاسيكي يعمل ببساطة وكنا نكره تعديل الكود خشية أن نثير غضب بعض الآلهة اليونانية التي ماتت منذ زمن طويل.

لقد طلبنا مؤخرًا إضافة ميزة إلى أحد التطبيقات.إن تنفيذ الميزة هو في الواقع مجرد عملية قاعدة بيانات تتطلب الحد الأدنى من التغيير في واجهة المستخدم.

لقد قمت بتغيير واجهة المستخدم وأجريت تعديلًا طفيفًا لإرسال قيمة بيانات جديدة إلى استدعاء sproc (sproc1).

في sproc1 الذي يتم استدعاؤه مباشرة من ASP، أضفنا استدعاءًا جديدًا إلى sproc آخر يصادف وجوده على خادم آخر، sproc2.

بطريقة ما، لا يعمل هذا عبر تطبيق ASP الخاص بنا، ولكنه يعمل في SQL Management Studio.

وإليكم التفاصيل الفنية:

1. SQL 2005 على كلا خوادم قاعدة البيانات.
2. تتم مصادقة تسجيل الدخول إلى Sql من تطبيق ASP إلى SQL 2005 Server 1.
3. الخادم المرتبط من الخادم 1 إلى الخادم 2 يعمل.
4. عند تنفيذ sproc1 من SQL Management Studio - يعمل بشكل جيد.حتى عند اعتماده باعتباره المستخدم نفسه الذي يستخدمه الكود الخاص بنا (تسجيل الدخول إلى SQL للتطبيق).
5. يعمل sproc2 عند استدعائه بشكل مستقل عن sproc1 من SQL Management Studio.
6. يلتقط VBScript (ASP) الخطأ الذي يتم إرساله في ملف XML إلى العميل.رقم الخطأ هو 0، وصف الخطأ فارغ.سواء من كائن ADODB.Connection أو من أي شيء ينتج عنه Err.Number/Err.Description في VBScript من جانب ASP.

لذلك دون أي أخطاء، ولا أي إمكانية تكرار نتائج (أي.من خلال SQL Mgmt Studio) - هل يعرف أحد المشكلة؟

تتمثل خطتنا الحالية في تحليل التعليمات البرمجية الموجودة على جانب ASP والتعمق فيها وإجراء مكالمة منفصلة تمامًا إلى Server 2.sproc2 مباشرةً من ASP بدلاً من محاولة الرجوع إلى sproc1.

Answer 1

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

سؤالي الأول هو هذا:ماذا يحدث إذا قمت بإزالة الجانب عبر الخادم من المعادلة؟إذا كان بإمكانك إعداد نظام اختبار حيث يقوم بروك الأول باستدعاء بروك الثاني، لكن بروك الثاني موجود على نفس الخادم و/أو في نفس قاعدة البيانات، فهل لا تزال تواجه نفس المشكلة؟

وعلى نفس المنوال:من خلال تجربتي، عندما يحصل التطبيق وSSMS على نتائج مختلفة من هذا القبيل، غالبًا ما يكون الأمر مشكلة تتعلق بإعدادات الإجراءات المخزنة.يمكن أن يكون، كما يقول لوقا، NOCOUNT.لقد حدث هذا النوع من الأشياء من عبارات PRINT الدخيلة في الكود، على الرغم من أنني أتذكر أن القيمة PRINTed أصبحت جزءًا من وصف الخطأ (بشكل غير متوقع للغاية).

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

فكرة أخيرة:وفي حالة ما إذا كان الأمر متعلقًا بالبيئة، فجرب إعدادات مختلفة على سلسلة الاتصال الخاصة بصفحة ASP الخاصة بك.على سبيل المثال، إذا كان لديك اتصال OLEDB، فجرب ODBC.جرب برامج تشغيل SQL Server الأصلية وغير الأصلية.تحقق من خيارات سلسلة الاتصال التي يدعمها مزود الخدمة الخاص بك، وجرب أيًا منها يبدو أنها تستحق التجربة.

Answer 2

هل لديك تعيين nocount على تعيين في كل من الإجراءات المخزنة؟لقد واجهت مشكلة مماثلة ذات مرة، وعلى الرغم من أنني لا أتذكر بالضبط كيف قمت بحلها في الوقت الحالي، فأنا أعلم أن لها علاقة بها!

Answer 3

من الممكن أن تعاني من مشكلة القفزة المزدوجة

تحدث مشكلة القفزة المزدوجة عندما تحاول صفحة ASP/X استخدام الموارد الموجودة على خادم مختلف عن خادم IIS.

تحدي/استجابة Windows NT لا يدعم انتحال صفة القفزة المزدوجة (حيث أنه بمجرد تمريرها إلى خادم IIS، لا يمكن تمرير نفس بيانات الاعتماد إلى خادم خلفي للمصادقة).

يجب عليك التحقق من محاولة الاتصال الثاني باستخدام منشئ ملفات التعريف SQL.

لاحظ أنه من خلال الاختبار اليدوي، فإنك لا تقوم بالمصادقة عبر IIS.تظهر هذه المشكلة فقط عند بدء SQL عبر صفحة ASP/X.

المزيد من الموارد:

• http://support.microsoft.com/kb/910449
• http://support.microsoft.com/kb/891031
• http://support.microsoft.com/kb/810572

Answer 4

واجهت مشكلة مماثلة وقمت بحلها عن طريق تعيين nocount على أوامر الطباعة وإزالتها.

Answer 5

قد يساعدك رمز المثال :) هل تحاول إرجاع جدولين من الإجراء المخزن؛لا أعتقد أن ADO 2.6 يمكنه التعامل مع جداول متعددة يتم إرجاعها.

Answer 6

لقد فكرت في ذلك (القفزة المزدوجة)، ولكن ما الفرق بين مكالمة sproc-in-a-sproc كما أشير إليها مقابل مكالمة sproc-in-a-sproc.الانضمام عبر الخادم النموذجي عبر INNER JOIN؟سيتم تنفيذ كلاهما على Server1، باستخدام بيانات اعتماد الخادم المرتبط، والمصادقة على الخادم 2.

هل يمكن لأي شخص التأكد من أن الاتصال بخادم sproc يختلف عن الانضمام إلى جداول البيانات؟و لماذا؟

إذا كان تكوين الخادم المرتبط عبارة عن حساب SQL - فهل يعتبر ذلك قفزة مزدوجة (نظرًا لأن ما تشير إليه هو قفزات NTLM المزدوجة؟)

فيما يتعلق بما إذا كانت مجموعات النتائج المتعددة ستعود أم لا - لا.سيكون كل من Server1.Sproc1 وServer2.Sproc2 "ExecuteNonQuery()" في عالم .net ولا يُرجعان شيئًا (لا توجد مجموعات نتائج ولا قيم إرجاع).

Answer 7

حاول التحقق من أذونات قاعدة البيانات للمستخدم المحدد في سلسلة الاتصال.استخدم نفس اسم المستخدم في سلسلة الاتصال لتسجيل الدخول إلى قاعدة البيانات أثناء استخدام sql mgmt studio.

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

Answer 8

هل يمكنني فقط التحقق من:قمت بإضافة sproc2؟قبل ذلك كان يعمل بشكل جيد على مر العصور.

هل لا يمكنك تغيير المكان الذي تتصل منه بـ sproc2؟بدلاً من الاتصال به من داخل sproc1، هل يمكنك الاتصال به من ASP؟وبهذه الطريقة يمكنك التحكم في مصادقة SQL في التعليمات البرمجية، ولا يتعين عليك الاعتماد على إعداد أي علاقات ثقة أو مصادقة مشتركة عن بعد على الخوادم.

Answer 9

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