एसक्यूएल सर्वर त्रुटि हैंडलिंग: अपवाद और डेटाबेस ग्राहक अनुबंध

Question

हम एसक्यूएल सर्वर डाटाबेस डेवलपर्स की एक टीम कर रहे हैं। हमारे ग्राहक सी #/एएसपी.नेट, सी # और जावा वेब सेवाओं, जावा/यूनिक्स सेवाओं और कुछ एक्सेल के मिश्रित बैग हैं।

हमारे क्लाइंट डेवलपर केवल संग्रहीत प्रक्रियाओं का उपयोग करते हैं जो हम प्रदान करते हैं और हम उम्मीद करते हैं कि (जहां समझदार, निश्चित रूप से) वे उन्हें वेब सेवा विधियों की तरह व्यवहार करते हैं।

कुछ हमारे ग्राहक डेवलपर्स एसक्यूएल अपवाद पसंद नहीं है। वे उन्हें अपनी भाषाओं में समझते हैं लेकिन वे इस बात की सराहना नहीं करते हैं कि एसक्यूएल सीमित है कि हम मुद्दों को कैसे संवाद कर सकते हैं।

मेरा मतलब सिर्फ एसक्यूएल त्रुटियों का नहीं है, जैसे कि इंट कॉलम में "बॉब" डालने का प्रयास करना।

मेरा मतलब है कि अपवाद जैसे कि उन्हें संदर्भ देना गलत है, या डेटा पहले ही बदल चुका है, या वे ऐसा नहीं कर सकते क्योंकि उनका कुल शून्य नहीं है।

उनके पास वास्तव में कोई ठोस विकल्प नहीं होगा: उन्होंने उल्लेख किया है कि हमें पैरामीटर आउटपुट करना चाहिए, लेकिन हम एक अपवाद मानते हैं "प्रसंस्करण बंद/लुढ़का हुआ।

कैसे लोग यहाँ डेटाबेस ग्राहक अनुबंध निपटेंगे? या तो आम तौर पर या जहां डीबी और क्लाइंट कोड बंदरों के बीच अलगाव होता है।

संपादन:

• उपयोग हम SQL सर्वर 2005 ट्राई/कैच विशेष रूप से
• तो एक अपवाद तालिका पहले से ही
• हम चिंतित हैं कि हमारे ग्राहकों में से कुछ जीत लिया 'के लिए रोलबैक के बाद सभी त्रुटियों को लॉग इन करें आउटपुट paramaters जांचें और मान लें कि सबकुछ ठीक है। हमें देखने के लिए समर्थन के लिए ध्वजांकित त्रुटियों की आवश्यकता है।
• सब कुछ एक अपवाद है ... ग्राहकों से अलग संदेश बनाम त्रुटियों को अलग करने के लिए कुछ संदेश पार्सिंग करने की उम्मीद है। डीबी इंजन और बुला त्रुटियों से हमारे अपवादों को अलग करने के लिए, वे त्रुटि संख्या का उपयोग करना चाहिए (हमारा पाठ्यक्रम के सभी 50,000 हैं)

Answer 1

वैसे मैं एक क्लाइंट कोड बंदर हूं जो डेटाबेस से बहुत संबंधित है। यहां बताया गया है कि मैं इसे कैसे संभालता हूं।

SQL में होने वाली अपवाद (raiseकर्ता) कॉलर पर वापस प्रचारित हो जाते हैं। इसमें रेफरी बाधाएं, अद्वितीय इंडेक्स उल्लंघन, अधिक गंभीर मुद्दे इत्यादि शामिल होंगे। मूल रूप से कुछ भी जो डेटा ऑपरेशन नहीं करेगा, सामान्य रूप से वापस प्रसारित किया जाना चाहिए।

फोन करने वाले सी # इस होना चाहिए:

catch (SQLException sqlEx) 

और फिर आवश्यकतानुसार अपवाद संभाल। उनके पास एक विशिष्ट SQLException हैंडलर होना चाहिए। यह महत्वपूर्ण है।

मैं आम तौर पर आउटपुट पैरामीटर से दूर रहता हूं क्योंकि मैं उन लोगों को डेटा से संबंधित होने के बारे में मानता हूं और कोई त्रुटि संदेश नहीं, इसके अतिरिक्त मैं SQL सर्वर त्रुटि कोड के लिए अपवाद का निरीक्षण कर सकता हूं ताकि हमारे द्वारा आवश्यक सभी डेटा में होना चाहिए वह अपवाद

इसके अतिरिक्त, SQL सर्वर के साथ कुछ मामलों में, हमारे पास संग्रहीत प्रक्रियाएं हैं जो "व्यावसायिक प्रकार के अपवाद" को बढ़ा सकती हैं। उन मामलों में हम एक कस्टम त्रुटि संख्या (50000 से ऊपर) जोड़ते हैं और आवश्यकता होने पर संग्रहीत प्रक्रिया में उस त्रुटि को उठाते हैं। आम तौर पर हम इसे कम से कम रखने की कोशिश करते हैं क्योंकि यह जटिलता को जोड़ता है, लेकिन कुछ मामलों में, हमने उन्हें आवश्यक पाया है।

अब, चूंकि क्लाइंट SQLException को पकड़ रहा है, इसलिए वे अपवाद में SQL सर्वर द्वारा लौटाए गए त्रुटि कोड को देख सकते हैं और फिर अपवाद पकड़े जाने पर कोई विशेष कार्रवाई (यदि आवश्यक हो) लेते हैं और त्रुटि संख्या निश्चित है मूल्य। यह कस्टम त्रुटियों (> 50000) के लिए आवश्यक होने पर त्रुटि कोड के आधार पर त्रुटि प्रबंधन के द्वितीयक स्तर की अनुमति देता है।

यह डीबीए को कस्टम त्रुटियों को बढ़ाने की अनुमति देता है और क्लाइंट कोड के साथ निपटने के लिए एक सतत तरीका है। डीबीए को क्लाइंट कोड बंदर को बताना होगा कि कस्टम त्रुटियां क्या थीं ताकि वे उनके लिए तैयार हो सकें।

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

Answer 2

मैं आम तौर पर एक आउटपुट पैरामीटर का उपयोग - और संभावित मान परिभाषित करते हैं।

0 = सफलता
Postive पूर्णांक (एक डालने पर मान लें) = नई पंक्ति आईडी (@@ पहचान)

नकारात्मक पूर्णांक = ज्ञात संभावित त्रुटि स्थितियां
-1 = गुम @LastName (या शून्य लंबाई)
-2 = गुम @FirstName (या शून्य लंबाई)
... आदि ...

इसमें कुछ समय कठिन हो जाता है परिभाषित करने के लिए - लेकिन यह एक्स्टेंसिबल हो सकता है - और यह एक तरह से सार्थक प्राप्त करने के लिए है आपके ग्राहकों को वापस परिणाम एक व्यापार ऑब्जेक्ट परत पर वापस जाने के लिए डेटा एक्सेस लेयर के लिए विफलता के लिए एक सटीक कारण है (मैं विभिन्न स्थिति स्थितियों के लिए व्यवसाय ऑब्जेक्ट्स परत में enums का उपयोग करता हूं)।

डेटा एक्सेस लेयर के लिए वांछित होने पर अपवाद फेंकना भी संभव है - लेकिन मुझे लगता है कि एक प्रदर्शन परिप्रेक्ष्य से लागत-वार पर आप त्रुटियों को फेंकने से बेहतर नहीं हैं जब आप केवल enum या integer value की जांच कर सकते हैं।

अन्य तकनीकें हैं - यह केवल एक है जिसे मैंने अतीत में कुछ सफलता के साथ उपयोग किया है।

वापसी 0 जब एक तार्किक त्रुटि hapens, गुम या अमान्य डेटा
वापसी सकारात्मक एक्स जब एक गंभीर त्रुटि तब होता है जब सब कुछ ठीक है
वापसी नकारात्मक एक्स, विफलता डालने, आदि:

Answer 3

यहाँ मेरी सिफारिश है

ऐड उत्पादन मानकों ERRORMSG और Errorlog संग्रहित प्रक्रियाओं पर। त्रुटिसंदेश एक मानव पठनीय संदेश में शामिल होंगे, Errorlog डिबग जानकारी शामिल होंगे।
ये शून्य अगर वापसी 0
आप किसी भी समस्याओं को दर्ज करने के Errorlog उपयोग कर सकते हैं, अगर आप उन्हें एक टेबल में डालने कर रहे हैं यह सुनिश्चित करने के लिए किया जाएगा, तो आप इसे रोलबैक के बाद करते हैं।

उपयोग TRY - पकड़ने समस्याओं पर कब्जा करने, और अपने खुद के संदेश का निर्माण, और जानकारी के ऊपर सम्मेलनों का उपयोग कर लौट आते हैं।

Answer 4

अपनी मौजूदा नौकरी में, हम असाधारण स्थितियों के लिए अपवाद सुरक्षित रखते हैं। बुरा पैरामीटर या तरह तरह की बातें के लिए, हम मानक वापसी कोड है - अवैध पैरामीटर मान हमेशा 98, उदाहरण के लिए। (क्यों 98? यह इतिहास के लिए खो गया है ...)

यह आवश्यक नहीं है कि ग्राहक बी और सी दोनों क्लाइंट और एसपी को समझना होगा कि एक विशेष रिटर्न कोड का क्या अर्थ है; यह चिंताओं का एक बुरा अलगाव है।

विशेष मामलों में, हम संदेशों पर लौटने के लिए मानकों को बाहर का उपयोग करें, और हमारे बैच सेवाओं एक मानकीकृत #scratch तालिका सेटअप का उपयोग करें।

एक पूर्व नियोक्ता में, हम एक ही उद्देश्यों के लिए कस्टम एसक्यूएल त्रुटियों का इस्तेमाल किया। तो, समझ में आता है क्या उपयोग करें। व्यक्तिगत रूप से, मैं एक ही तंत्र को पसंद करते हैं, लेकिन वह अपने परिवेश के आधार पर संभव नहीं हो सकता।

शायद तुम सब एक साथ पाने के लिए ग्राहक कोड के लिए मानकीकृत तरीके इसे संभाल करने के लिए विकसित करने के लिए चाहिए। VBA एक्सेल में इस्तेमाल विशिष्ट सीमाओं कि सी # और जावा कोड नहीं करते हैं, और के रूप में जावा & सी # रूप में इसी तरह एक दूसरे के लिए कर रहे हैं, वे समान नहीं कर रहे हैं। यदि आप रिटर्निंग अपवाद के साथ चिपकने जा रहे हैं, तो यदि आप किसी पर सहमत हो सकते हैं) एक ज्ञात संदेश # श्रेणी जो "त्रुटि" अपवादों को इंगित करती है और बी) मानकीकृत संदेश लेआउट ताकि मानक पार्सिंग हो सके, डेवलपर्स होंगे 9 0% किया गया।