2009-05-04 16 views
5

मैंने कई वर्षों से एसक्यूएल के साथ काम किया है, मुख्य रूप से MySQL/PhpMyAdmin, लेकिन हाल ही में ओरेकल/आईएसक्लप्लस और पीएल/एसक्यूएल भी। मैंने PHP, जावा, एक्शनस्क्रिप्ट और अधिक में प्रोग्राम किया है। मुझे एहसास है कि एसक्यूएल दूसरों की तरह एक अनिवार्य प्रोग्रामिंग भाषा नहीं है - लेकिन त्रुटि संदेशों को एसक्यूएल में इतना कम विशिष्ट क्यों लगता है? अन्य वातावरण में मैं सीधे समस्या की जड़ की ओर इशारा करता हूं। अधिकतर नहीं, MySQL मुझे त्रुटियों देता है जैसे "त्रुटि AROUND जहां u.id = ..." और पूरी क्वेरी प्रिंट करता है। संग्रहीत प्रक्रियाओं के साथ यह और भी मुश्किल है, जहां डीबगिंग एक पूर्ण दुःस्वप्न हो सकता है।एसक्यूएल डीबग करने का कोई बेहतर तरीका है?

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

+5

एक शिकायत एक उचित सवाल से भी अधिक की तरह लगता है है। क्या आप एक बेहतर डीबगर चाहते हैं? क्या आप एक बेहतर डेटाबेस चाहते हैं? आप क्या तय करना चाहते हैं? वह कोड कहां काम नहीं करता है? –

+0

एसएलॉट –

+0

का उत्तर देने के लिए अद्यतन प्रश्न शायद आपके प्रश्न को फिर से लिखना अच्छा होगा जैसे "एसक्यूएल से बेहतर (अधिक विस्तृत) त्रुटि संदेश प्राप्त करने का कोई तरीका है"। अन्यथा आप "प्रश्न नहीं" के रूप में बंद होने का सामना कर सकते हैं। – lothar

उत्तर

5

मुझे लगता है कि उत्तर इस तथ्य में निहित है कि एसक्यूएल कुछ प्रक्रियात्मक चीजों के साथ एक सेट-आधारित भाषा है। चूंकि डिजाइनर सेट-आधारित शर्तों में सोच रहे थे, इसलिए उन्होंने नहीं सोचा था कि अन्य भाषाओं में डीबगिंग का सामान्य प्रकार महत्वपूर्ण है। हालांकि, मुझे लगता है कि इनमें से कुछ बदल रहा है। आप SQL Server 2008 में ब्रेकपॉइंट्स सेट कर सकते हैं। मैंने इसे वास्तव में उपयोग नहीं किया है क्योंकि आपके पास काम करने से पहले SQL Server 2008 डेटाबेस होना चाहिए और हमारे अधिकांश अभी भी SQL Server 2000 हैं। लेकिन यह उपलब्ध है और यह आपको चरणबद्ध करने की अनुमति देता है बातें। जब भी आपका चयन कथन 150 लाइन लंबा होता है और यह जानता है कि सिंटैक्स सही नहीं है लेकिन यह बिल्कुल सही नहीं कह सकता है कि यह एक ही आदेश है, तो आपको अभी भी समस्याएं आ रही हैं।

व्यक्तिगत रूप से जब मैं एक लंबी प्रक्रियात्मक एसपी लिख रहा हूं, तो मैं एक परीक्षण मोड में निर्माण करता हूं जिसमें मुझे मेरे द्वारा किए गए कार्यों के परिणाम, महत्वपूर्ण बिंदुओं पर महत्वपूर्ण चर के मूल्य, और उन स्टैमेंट प्रिंट करने में शामिल हैं मुझे पता है कि क्या कदम पूरा हो गए हैं और फिर पूरा होने पर पूरी चीज को वापस ले जाना। इस तरह से मैं देख सकता हूं कि क्या हुआ होगा अगर यह वास्तविक के लिए चलाया गया था, लेकिन अगर मुझे यह गलत लगता है तो डेटाबेस में किसी भी डेटा को चोट नहीं पहुंची है। मुझे यह बहुत उपयोगी लगता है। हालांकि यह आपकी proc के आकार को काफी बढ़ा सकता है। मेरे पास एक टेम्पलेट है जिसका उपयोग मैं करता हूं जिसमें अधिकांश संरचनाएं स्थापित होती हैं, इसलिए मुझे वास्तव में ऐसा करने में बहुत लंबा समय नहीं लगता है। खासकर जब से मैं कभी भी एक सम्मिलित नहीं करता हूं। यह सुनिश्चित करने के लिए कि मेरे पास इच्छित रिकॉर्ड हैं, पहले चयनित चयन का परीक्षण किए बिना किसी प्रो को अपडेट या हटाएं।

1

मैं आपकी शिकायत से सहमत हूं।

एक अच्छा लॉगिंग ढांचा बनाना और इसे अपने sprocs में overusing करना मेरे लिए सबसे अच्छा काम करता है।

प्रत्येक लेनदेन या तर्क के महत्वपूर्ण टुकड़े से पहले और बाद में, मैं अपनी लॉग तालिका में स्पोक नाम, चरण टाइमस्टैम्प और एक पंक्ति गणना (यदि प्रासंगिक हो) लिखता हूं। मुझे लगता है कि जब मैंने यह किया है, तो मैं आमतौर पर समस्या को कुछ ही मिनटों में सीमित कर सकता हूं।

स्पोक में एक डीबग पैरामीटर जोड़ें (डिफ़ॉल्ट रूप से "एन") जोड़ें और इसे किसी भी अन्य स्पॉक्स के माध्यम से पास करें जिससे कि आप आसानी से लॉग ऑन चालू या बंद कर सकें।

3

मुझे लगता है कि स्पष्टीकरण यह है कि "नियमित" भाषाओं में एसक्यूएल की तुलना में बहुत छोटे व्यक्तिगत विवरण होते हैं, ताकि एकल-कथन ग्रैन्युलरिटी एसक्यूएल की तुलना में कोड के बहुत छोटे हिस्से को इंगित करे। एक एकल SQL कथन लंबाई में एक पृष्ठ या अधिक हो सकता है; अन्य भाषाओं में यह आमतौर पर एक पंक्ति है।

मुझे नहीं लगता कि यह डीबगर्स/आईडीई के लिए त्रुटियों की पहचान करने के लिए असंभव बनाता है, लेकिन मुझे संदेह है कि यह कठिन हो जाता है।

1

ब्रेकपॉइंट्स और कोड के माध्यम से कदम उठाने के लिए, आप इसे एमएस एसक्यूएल सर्वर के साथ कर सकते हैं (मेरी राय में, 2000 के मुकाबले 2005+ पर यह आसान है)।

साधारण मामलों के लिए, प्रारंभिक विकास डीबगिंग, कभी-कभी क्रिप्टिक संदेश आमतौर पर त्रुटि हल करने के लिए पर्याप्त होते हैं - वाक्यविन्यास त्रुटि, वाई के साथ एक्स नहीं कर सकता। अगर मैं एक कठिन स्पोक में हूं, तो मैं ' स्पोक टेक्स्ट पर "printf डीबगिंग" पर वापस आ जाएगा क्योंकि यह तेज़ और आसान है। थोड़ी देर के बाद अपने पसंद के डेटाबेस के साथ, साधारण मुद्दे पुराने टोपी बन जाते हैं और आप उन्हें सीधे ले जाते हैं।

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

0

मैं निम्नलिखित रणनीति का उपयोग करता हूं।

संग्रहीत प्रक्रिया के लेखन के दौरान @procStep var प्रत्येक बार एक नया लॉजिकल चरण निष्पादित किया जाता है सेट @procStep = "क्या ... यहाँ हो रहा है";

बाकी here

संबंधित मुद्दे

 संबंधित मुद्दे