यह कोई फर्क नहीं पड़ता कि आप इसे कैसे देखते हैं, एक बग। एसक्यूएल प्रोफाइलर "टेक्स्टडाटा" का इरादा किसी को संग्रहीत प्रक्रिया कॉल को समझने और दोहराने में सक्षम बनाना है। इस मामले में, इस टी-एसक्यूएल को चलाने से आपको पूरी तरह से अलग परिणाम मिल सकता है, यदि spStoredProcedure प्रक्रिया @OutParam पैरामीटर के इनपुट मान पर कोई तर्क निर्भर है, जहां "13" का मान किसी इनपुट मूल्य के रूप में अर्थपूर्ण था ।
यह देखना आसान है कि यह सुविधाजनक कैसे हो सकता है (आपको प्रो कॉल के आउटपुट मान देखने में सक्षम बनाता है, जिसे अन्यथा "आरपीसी आउटपुट पैरामीटर" ईवेंट के साथ करने की आवश्यकता होती है), लेकिन यह प्रभावी रूप से "झूठ" टी-एसक्यूएल समकक्ष को किस प्रकार निष्पादित किया गया था।
संबंधित: मैं बस माइक्रोसॉफ्ट कस्टमर सर्विस और सपोर्ट टीम के एक लेख में आया - एक और मामले के बारे में जहां आरपीसी का रूपांतरण: पूर्ण घटना के बाइनरीडेटा को एक प्रदर्शित करने योग्य टेक्स्टडेटा मान में मूल आरपीसी कॉल का गलत प्रजनन होता है - यह समय कोडपेज मुद्दे:
http://blogs.msdn.com/b/psssql/archive/2008/01/24/how-it-works-conversion-of-a-varchar-rpc-parameter-to-text-from-a-trace-trc-capture.aspx
UPDATED: इस के साथ प्रयोग करके, मैं व्यवहार का एक और खास मिला - प्रोफाइलर केवल यह गलत प्रारंभिक सेट का उपयोग करेगा, तो उस पैरामीटर के लिए इनपुट मूल्य, RPC कॉल में, Null था । यदि एक गैर-शून्य मान प्रदान किया गया था (और पैरामीटर, .Net SqlClient में, "इनपुट आउटपुट" दिशा थी), तब प्रारंभिक एसईटी में वास्तविक इनपुट मान होता है, न कि परिणामस्वरूप आउटपुट मान। लेकिन अगर इनपुट शून्य था, तो आउटपुट मान इसके बजाय सेट किया गया है। यह अवलोकन इस धारणा का समर्थन करता है कि यह प्रोफाइलर आरपीसी-टू-टीएसक्यूएल डिस्प्ले रूपांतरण में बस एक नल-हैंडलिंग बग है।
? क्योंकि यह जिस तरह से प्रदर्शित होता है ?? सवाल कहां है? –
ठीक है, जिस तरह से यह प्रदर्शित होता है, यह संग्रहीत प्रक्रिया को निष्पादित करने से पहले आउटपुट पैरामीटर के मूल्य का आकलन कर रहा है। यह स्पष्ट रूप से आदेशों का अनुक्रम नहीं है, इसलिए मैं सोच रहा था कि यह इस तरह प्रदर्शित क्यों होता है। –