सबसे पहले, यदि आप SQL*Plus का उपयोग कर रहे हैं, जब आप कोई ऑब्जेक्ट बनाते हैं और कहा जाता है कि संकलन त्रुटियां हैं, तो कमांड show errors आपको त्रुटियां दिखाएगा।
अगर आपने show errors ran चलाया है , आपको बताया जाएगा कि IF EXISTS मान्य वाक्यविन्यास नहीं है। आप कुछ ऐसा कर सकते हैं
SELECT COUNT(*)
INTO l_cnt
FROM <<rest of query>>
IF( l_cnt > 0 )
THEN
RAISE_APPLICATION_ERROR ...
END IF;
एक बार जब आप संकलन त्रुटि को ठीक कर लेते हैं, तो आप रनटाइम त्रुटियों के साथ समाप्त हो जाएंगे। surveillance . पर एक पंक्ति-स्तरीय ट्रिगर में , आप आम तौर पर surveillance . को क्वेरी नहीं कर सकते (यदि आप केवल एक INSERT VALUES . कर रहे हैं, तो आप कर सकते हैं यह केवल एक पंक्ति डालने की गारंटी है)। यदि आप ऐसा करते हैं, तो आपको रनटाइम पर एक उत्परिवर्तित ट्रिगर त्रुटि प्राप्त होगी।
डेटा मॉडल के नजरिए से, जब आप खुद को एक टेबल डिजाइन करते हुए पाते हैं जिसमें किसी विशेष पंक्ति के लिए वैध डेटा उसी टेबल की अन्य पंक्तियों में संग्रहीत डेटा पर निर्भर करता है, तो आपने आम तौर पर सामान्यीकरण सिद्धांतों का उल्लंघन किया है और आप आमतौर पर बेहतर तरीके से फिक्सिंग करते हैं। अंतर्निहित डेटा मॉडल।
यदि आप डेटा मॉडल को बनाए रखने के लिए वास्तव में दृढ़ हैं, तो मैं एक भौतिक दृश्य बनाना पसंद करूंगा जो प्रतिबद्धता पर ताज़ा हो जिसमें केवल उन पंक्तियों के लिए डेटा हो जो आपके मानदंडों का उल्लंघन करते हैं। फिर आप उस भौतिक दृष्टिकोण पर बाधा डाल सकते हैं जो आपके मानदंडों का उल्लंघन होने पर प्रतिबद्ध समय पर त्रुटियों को फेंक देता है। इसके लिए आपकी टेबल पर भौतिक दृश्य लॉग की आवश्यकता होगी।
यदि आप वास्तव में डेटा मॉडल रखना चाहते हैं और आप ट्रिगर के साथ तर्क को लागू करना चाहते हैं, तो आपको क्लासिक तीन ट्रिगर समाधान (या यदि आप 11.2 या बाद के संस्करण का उपयोग कर रहे हैं तो तीन भागों के साथ एक कंपाउंड ट्रिगर) की आवश्यकता होगी। आप प्राथमिक कुंजी मानों के संग्रह के साथ एक पैकेज बनाएंगे। पहले स्टेटमेंट ट्रिगर संग्रह को इनिशियलाइज़ करेगा। एक पंक्ति-स्तरीय ट्रिगर इस संग्रह में सम्मिलित और/या अद्यतन की गई पंक्तियों की प्राथमिक कुंजियाँ सम्मिलित करेगा। और फिर एक आफ्टर स्टेटमेंट ट्रिगर इस संग्रह पर पुनरावृति करेगा और जो भी चेक आप चाहते हैं उसे लागू करें। हालांकि, यह बहुत सारे चलते हुए टुकड़े हैं, यही वजह है कि मैं आमतौर पर इसके खिलाफ सलाह देता हूं।
इसके अलावा, भले ही आप इन सभी टुकड़ों को काम कर लें, आपका तर्क बहु-उपयोगकर्ता वातावरण में आपकी रक्षा नहीं करेगा। जब आपके पास एक ही समय में कई उपयोगकर्ता सिस्टम को हिट करते हैं, तो यह पूरी तरह से संभव है कि एक उपयोगकर्ता एक पंक्ति सम्मिलित करेगा, दूसरा उपयोगकर्ता एक ओवरलैपिंग रेंज के साथ दूसरी पंक्ति सम्मिलित करेगा, और फिर प्रत्येक सत्र प्रतिबद्ध होगा। उस स्थिति में, ट्रिगर के दोनों सेट परिवर्तन की अनुमति देंगे लेकिन फिर भी आपके पास तालिका में डेटा बचा रहेगा जो आपकी आवश्यकताओं का उल्लंघन करता है। भौतिक दृश्य, चूंकि इसे डालने के समय के बजाय प्रतिबद्ध समय पर लागू किया जाता है, यह बहु-उपयोगकर्ता वातावरण में ठीक से काम करेगा। यदि आप चाहते हैं कि ट्रिगर एक बहु-उपयोगकर्ता वातावरण में काम करें, तो आपको अतिरिक्त तर्क जोड़कर उन्हें और अधिक जटिल बनाना होगा जो क्रमांकन को लागू करता है जो दूसरे सत्र के insert को अवरुद्ध कर देगा। चलने से पहले सत्र तक या तो प्रतिबद्ध या वापस लुढ़क गया। यह जटिलता जोड़ता है, मापनीयता को कम करता है, और इसे कैसे लागू किया जाता है, इस पर निर्भर करते हुए, एक समर्थन दुःस्वप्न बन सकता है।
