यूडीएफ के अंदर TRY-CATCH ब्लॉक की अनुमति क्यों नहीं है?

Question

क्यों SQL सर्वर UDF के अंदर TRY-CATCH ब्लॉक का समर्थन नहीं करता है?

यदि हम स्केलर यूडीएफ के बारे में बात कर रहे हैं, जो ज्यादातर गणना और बातचीत के लिए उपयोग किए जाते हैं, तो इस ब्लॉक का भारी उपयोग किया जाना चाहिए, लेकिन हमारे पास यह नहीं है।

इसके अलावा, आप इसके लिए किस कामकाज का उपयोग करते हैं?

Answer 1

एमएसएसक्यूएल में यूडीएफ को दुष्प्रभाव होने की अनुमति नहीं है, जिसे बीओएल "डेटाबेस स्थिति बदलना" के रूप में परिभाषित करता है। यही कारण है कि एक नहीं बल्कि अस्पष्ट विवरण दिया गया है, लेकिन जाहिरा तौर पर MSSQL डेटाबेस स्थिति बदलने में त्रुटियों पर विचार करता है - इस यूडीएफ संकलन नहीं करता है:

create function dbo.foo() 
returns int 
as 
begin 
    raiserror('Foo', 16, 1) 
    return 1 
end 
go 

त्रुटि संदेश है:

संदेश 443, स्तर 16, राज्य 14 , प्रक्रिया foo, लाइन 5 एक फ़ंक्शन के भीतर साइड-इफेक्टिंग ऑपरेटर 'RAISERROR' का अमान्य उपयोग।

यदि कोई त्रुटि उठाना डेटाबेस स्थिति को बदलने के लिए माना जाता है, तो संभावित रूप से फँसाना और संभालना भी है। जो एक स्पष्टीकरण नहीं है, मैं मानता हूं।

व्यावहारिक शब्दों में, हालांकि, कॉलर को यह तय करना सबसे अच्छा होता है कि वैसे भी त्रुटियों को कैसे संभालना है।

create function dbo.divide (@x int, @y int) 
returns float 
as 
begin 
return @x/cast(@y as float) 
end 

कैसे आप इस मामले में जहां एक आवेदन @y के लिए शून्य से गुजरता संभाल होगा: आप इस तरह एक समारोह लिखने कहो? यदि आप शून्य अपवाद से विभाजन को पकड़ते हैं, तो आप आगे क्या करने जा रहे हैं? कॉलर को समझ में आने वाले फ़ंक्शन से आप किस मूल्य से वापस आ सकते हैं, इस बात को ध्यान में रखते हुए कि आप यह भी नहीं जानते कि कौन सा एप्लिकेशन आपके फ़ंक्शन को कॉल कर रहा है?

आप न्यूल लौटने के बारे में सोच सकते हैं, लेकिन क्या आपके डेवलपर का उपयोग करने वाले एप्लिकेशन डेवलपर्स सहमत होंगे? क्या उनके सभी अनुप्रयोग समान प्रभाव या महत्व के लिए शून्य त्रुटि से विभाजित मानते हैं? उल्लेख नहीं है कि कुछ स्थानों में एनयूएलएल एक प्रश्न के परिणामों को पूरी तरह से बदल सकता है, शायद इस तरह से कि एप्लिकेशन डेवलपर बिल्कुल नहीं चाहता है।

यदि आप एकमात्र डेवलपर हैं, तो शायद यह कोई मुद्दा नहीं है, लेकिन अधिक लोगों के साथ यह जल्दी से एक बन जाता है।

Answer 2

आसपास के काम के रूप में, मैं यूडीएफ को संग्रहीत प्रक्रिया के अंदर TRY/CATCH से कॉल करता हूं।

Answer 3

शायद ऐसा इसलिए है क्योंकि ओवरहेड बहुत अधिक है - कॉलम पर एक स्केलर फ़ंक्शन को चुनने के लिए चुना जा सकता है और इसे हजारों बार बुलाया जा सकता है। यदि कोशिश करने/पकड़ने की अनुमति देने के लिए उचित ओवरहेड था तो यह इसे धीमा कर देगा।