एक्सेस ओडीबीसी डेटा स्रोतों से कैसे बात करता है? भाग 5

रिकॉर्डसेट को फ़िल्टर करना

हमारी श्रृंखला के भाग 5 में, हम सीखेंगे कि Microsoft Access कैसे कार्यान्वित फ़िल्टर को संभालता है और उन्हें ODBC प्रश्नों में एकीकृत करता है। पिछले लेख में, हमने देखा था कि कैसे एक्सेस SELECT . को तैयार करेगा ODBC SQL कमांड में स्टेटमेंट। हमने पिछले लेख में यह भी देखा था कि कैसे एक्सेस एक WHERE . लागू करके एक पंक्ति को अपडेट करने का प्रयास करेगा कुंजी के आधार पर क्लॉज और यदि लागू हो, रोवर्जन। हालांकि, हमें यह जानने की जरूरत है कि एक्सेस क्वेरी को प्रदान किए गए फिल्टर को एक्सेस कैसे संभालेगा और उन्हें ओडीबीसी परत में अनुवादित करेगा। एक्सेस क्वेरी कैसे तैयार की जाती है, इसके आधार पर एक्सेस का उपयोग करने के लिए अलग-अलग दृष्टिकोण हैं और आप सीखेंगे कि कैसे एक्सेस क्वेरी को ओडीबीसी क्वेरी में दिए गए अलग-अलग फ़िल्टर विधेय के लिए अनुवाद करेगा।

भले ही आप वास्तव में फ़िल्टर कैसे लागू करते हैं - यह फॉर्म या डेटाशीट के रिबन कमांड या राइट-मेनू क्लिक के माध्यम से अंतःक्रियात्मक रूप से हो, या प्रोग्रामेटिक रूप से VBA का उपयोग कर रहा हो या सहेजी गई क्वेरी चला रहा हो - फ़िल्टरिंग करने के लिए एक्सेस एक संबंधित ODBC SQL क्वेरी जारी करेगा। सामान्य तौर पर, एक्सेस जितना संभव हो उतना फ़िल्टरिंग करने का प्रयास करेगा। हालाँकि, यह आपको नहीं बताएगा कि क्या यह ऐसा नहीं कर सकता है। इसके बजाय, यदि एक्सेस ODBC SQL सिंटैक्स का उपयोग करके फ़िल्टर को व्यक्त नहीं कर सकता है, तो यह इसके बजाय तालिका की संपूर्ण सामग्री को डाउनलोड करके और स्थानीय रूप से स्थिति का मूल्यांकन करके स्वयं फ़िल्टरिंग करने का प्रयास करेगा। यह समझा सकता है कि कभी-कभी आपको एक ऐसी क्वेरी का सामना करना पड़ सकता है जो जल्दी से चलती है लेकिन एक छोटे से बदलाव के साथ क्रॉल में धीमी हो जाती है। उम्मीद है कि यह अनुभाग आपको यह समझने में मदद करेगा कि ऐसा कब हो सकता है और इसे कैसे संभालना है ताकि आप फ़िल्टर को लागू करने के लिए डेटा स्रोतों तक जितना हो सके रिमोट एक्सेस करने में मदद कर सकें।

इस लेख के लिए, हम सहेजी गई क्वेरी का उपयोग करेंगे, लेकिन यहां चर्चा की गई जानकारी अभी भी फ़िल्टर लगाने के अन्य तरीकों पर लागू होनी चाहिए।

स्थिर फ़िल्टर

हम आसान शुरुआत करेंगे और हार्ड-कोडेड फ़िल्टर के साथ एक सहेजी गई क्वेरी बनाएंगे।

c.CityID ,c.CityName ,c.StateProvinceIDFROM शहरों के रूप में चुनें जहां c.CityName="Boston";

SQLExecDirect:"सी" चुनें। वाक्य रचना में परिवर्तन के अलावा, क्वेरी का शब्दार्थ नहीं बदला है; एक ही फिल्टर के रूप में पारित किया जाता है। ध्यान दें कि केवल CityID का चयन किया गया था क्योंकि डिफ़ॉल्ट रूप से एक क्वेरी एक डायनासेट-प्रकार के रिकॉर्डसेट का उपयोग करती है जिसकी चर्चा हम पहले ही कर चुके हैं।
 
सरल पैरामीटरयुक्त फ़िल्टर
 

 आइए इसके बजाय पैरामीटर का उपयोग करने के लिए SQL को बदलें:
 
PARAMETERS SelectedCityName Text ( 255 ); Select c.CityID ,c.CityName ,c.StateProvinceIDFROM शहरों के रूप में c.CityName=[SelectedCityName];
 यदि हम दिखाए गए पैरामीटर प्रॉम्प्ट मान में क्वेरी और इनपुट "बोस्टन" चलाते हैं, तो हमें निम्नलिखित ODBC ट्रेस SQL ​​देखना चाहिए:
 
SQLExecDirect:"सी" चुनें। " WHERE ("सिटीनाम" =? ) 
 ध्यान दें कि हम नियंत्रण संदर्भों या सबफ़ॉर्म लिंकिंग के साथ समान व्यवहार का निरीक्षण करेंगे। अगर हमने इसके बजाय इसका इस्तेमाल किया:
 
चुनें c.CityID ,c.CityName ,c.StateProvinceIDFROM शहरों से जहां c.CityName=[Forms]![frmSomeForm]![txtSomeText];
 हमें अभी भी वही ट्रेस किया गया ODBC SQL मिलेगा जो हमने मूल पैरामीटरयुक्त क्वेरी के साथ देखा था। हमारी संशोधित क्वेरी में PARAMETERS . नहीं होने के बावजूद भी ऐसा ही है बयान। इससे पता चलता है कि एक्सेस यह पहचानने में सक्षम है कि ऐसे नियंत्रण संदर्भ जिनके मूल्य समय-समय पर बदल सकते हैं, उन्हें ओडीबीसी एसक्यूएल बनाते समय एक पैरामीटर के रूप में सबसे अच्छा माना जाता है।
 

 वह भी वीबीए समारोह के लिए काम करता है। हम एक नया VBA फ़ंक्शन जोड़ सकते हैं:
 
पब्लिक फंक्शन GetSelectedCity() स्ट्रिंग के रूप में GetSelectedCity ="बोस्टन" एंड फंक्शन
 हम सहेजी गई क्वेरी को नए VBA फ़ंक्शन का उपयोग करने के लिए समायोजित करते हैं:
 
कहां c.CityName=GetSelectedCity();
 यदि आप इसे ट्रेस करते हैं, तो आप देखेंगे कि यह अभी भी वही है। इस प्रकार, हमने प्रदर्शित किया है कि इनपुट एक स्पष्ट पैरामीटर है, एक नियंत्रण का संदर्भ है, या एक वीबीए फ़ंक्शन का परिणाम है, एक्सेस उन सभी को ओडीबीसी एसक्यूएल क्वेरी के पैरामीटर के रूप में मानेगा जिसे यह हमारे पर निष्पादित करेगा की ओर से। यह एक अच्छी बात है क्योंकि हम आम तौर पर बेहतर प्रदर्शन प्राप्त करते हैं जब हम किसी क्वेरी का पुन:उपयोग कर सकते हैं और केवल पैरामीटर बदल सकते हैं।
 

 हालांकि, एक और सामान्य परिदृश्य है जिसे एक्सेस डेवलपर्स आमतौर पर सेट करते हैं और वह है वीबीए कोड के साथ गतिशील एसक्यूएल बनाना, आमतौर पर एक स्ट्रिंग को जोड़कर और फिर समेकित स्ट्रिंग को निष्पादित करके। आइए निम्नलिखित VBA कोड का उपयोग करें:
 
सार्वजनिक उप GetSelectedCities() Dim db as DAO.Database Dim rs as DAO.Recordset Dim fld as DAO.Field Dim SelectCity as String Dim SQLStatement as String SelectedCity =InputBox("एक शहर का नाम दर्ज करें") SQLStatement =_ "SELECT c.CityID, c.CityName, c.StateProvinceID " &_ "FROM Cities AS c" &_ "WHERE c.CityName ='" और SelectedCity &"';" सेट db =CurrentDb सेट rs =db.OpenRecordset(SQLStatement) rs.EOF तक प्रत्येक fld के लिए rs.Fields Debug.Print fld.Value; अगला डिबग.प्रिंट rs.MoveNext लूपएंड सब
 OpenRecordset . के लिए ट्रेस किया गया ODBC SQL इस प्रकार है:
 
SQLExecDirect:"सी" चुनें। पिछले उदाहरणों के विपरीत, ODBC SQL को पैरामीटरकृत नहीं किया गया था। एक्सेस के पास यह जानने का कोई तरीका नहीं है कि 'बोस्टन' गतिशील रूप से रनटाइम पर VBA.InputBox द्वारा पॉप्युलेट किया गया था . हमने इसे केवल निर्मित एसक्यूएल दिया है जो एक्सेस 'पीओवी से, सिर्फ एक स्थिर एसक्यूएल स्टेटमेंट है। इस मामले में, हम क्वेरी के पैरामीटरकरण को हराते हैं। यह पहचानना महत्वपूर्ण है कि एक्सेस डेवलपर्स को दी गई एक लोकप्रिय सलाह यह है कि गतिशील रूप से निर्मित एसक्यूएल पैरामीटर प्रश्नों का उपयोग करने से बेहतर है क्योंकि यह उस समस्या से बचा जाता है जहां एक्सेस इंजन एक पैरामीटर मान के आधार पर निष्पादन योजना उत्पन्न कर सकता है जो वास्तव में दूसरे के लिए उप-इष्टतम हो सकता है पैरामीटर मान। उस घटना के बारे में अधिक जानकारी के लिए, मैं आपको "पैरामीटर-सूँघने" की समस्या पर पढ़ने के लिए प्रोत्साहित करता हूं। ध्यान दें कि यह किसी भी डेटाबेस इंजन के लिए एक सामान्य समस्या है, न कि केवल एक्सेस के लिए। हालाँकि, एक्सेस के मामले में, डायनेमिक SQL ने बेहतर काम किया क्योंकि यह केवल एक नई निष्पादन योजना बनाने के लिए बहुत सस्ता है। इसके विपरीत, एक RDBMS इंजन में समस्या से निपटने के लिए अतिरिक्त रणनीतियाँ हो सकती हैं और यह बहुत अधिक एकबारगी निष्पादन योजनाओं के प्रति अधिक संवेदनशील हो सकता है क्योंकि यह इसके कैशिंग को नकारात्मक रूप से प्रभावित कर सकता है।
 

 उस कारण से, ओडीबीसी स्रोतों के विरुद्ध एक्सेस से पैरामीटरयुक्त प्रश्न डायनेमिक SQL पर बेहतर हो सकते हैं। चूंकि एक्सेस किसी प्रपत्र या वीबीए फ़ंक्शन पर संदर्भ नियंत्रणों का इलाज करेगा, जिसके लिए पैरामीटर के रूप में कॉलम संदर्भों की आवश्यकता नहीं होती है, आपको अपने रिकॉर्ड स्रोतों या पंक्ति स्रोतों में स्पष्ट पैरामीटर की आवश्यकता नहीं होती है। हालाँकि, यदि आप SQL को निष्पादित करने के लिए VBA का उपयोग कर रहे हैं, तो आमतौर पर ADO का उपयोग करना बेहतर होता है, जिसमें पैरामीटर के लिए बेहतर समर्थन भी होता है। एक गतिशील रिकॉर्ड स्रोत या पंक्ति स्रोत के निर्माण के मामले में, प्रपत्र/रिपोर्ट पर एक छिपे हुए नियंत्रण का उपयोग करना क्वेरी को पैरामीटर करने का एक आसान तरीका हो सकता है। हालाँकि, यदि क्वेरी स्पष्ट रूप से भिन्न है, तो VBA में डायनेमिक SQL का निर्माण करना और इसे रिकॉर्डसोर्स/रोसोर्स प्रॉपर्टी को असाइन करना प्रभावी रूप से एक पूर्ण पुनर्संकलन को मजबूर करता है और इसलिए खराब निष्पादन योजनाओं का उपयोग करने से बचें जो इनपुट के वर्तमान सेट के लिए अच्छा प्रदर्शन नहीं करेंगे। आपको SQL सर्वर के WITH RECOMPILE . पर चर्चा करने वाले आलेख में अनुशंसाएं मिल सकती हैं यह तय करने में मददगार है कि क्या एक पैरामीटरयुक्त क्वेरी का उपयोग करके एक पुनर्संकलन को बाध्य करना है।
 
SQL फ़िल्टरिंग में फ़ंक्शन का उपयोग करना
 

 पिछले खंड में, हमने देखा कि VBA फ़ंक्शन वाले SQL स्टेटमेंट को पैरामीटराइज़ किया गया ताकि एक्सेस VBA फ़ंक्शन को निष्पादित कर सके और आउटपुट को पैरामीटरयुक्त क्वेरी के इनपुट के रूप में उपयोग कर सके। हालांकि, सभी अंतर्निहित कार्य इस तरह से व्यवहार नहीं करते हैं। आइए UCase() का उपयोग करें क्वेरी को फ़िल्टर करने के लिए एक उदाहरण के रूप में। इसके अलावा, हम फ़ंक्शन को एक कॉलम पर लागू करेंगे।
 
चुनें c.CityID ,c.CityName ,c.StateProvinceIDFROM शहरों के रूप में जहां UCase([c].[CityName])="BOSTON";
 यदि हम ट्रेस किए गए ODBC SQL को देखें, तो हम इसे देखेंगे:
 
SQLExecDirect:"सी" चुनें। पिछले उदाहरण में, एक्सेस GetSelectedCity() . को पूरी तरह से पैरामीटराइज़ करने में सक्षम था चूंकि इसे क्वेरी में संदर्भित कॉलम से किसी इनपुट की आवश्यकता नहीं है। हालांकि, UCase() एक इनपुट की आवश्यकता है। अगर हमने UCase("Boston") . प्रदान किया होता , एक्सेस ने इसे भी दूर कर दिया होगा। हालाँकि, इनपुट एक कॉलम संदर्भ है, जिसे एक्सेस आसानी से दूर नहीं कर सकता है। हालांकि, एक्सेस यह पता लगा सकता है कि UCase() समर्थित ODBC अदिश कार्यों में से एक है। चूंकि हम डेटा स्रोत के लिए जितना संभव हो सके रिमोट करना पसंद करते हैं, एक्सेस केवल ओडीबीसी के ucase के संस्करण को लागू करके करता है। ।
 

 यदि हम एक कस्टम VBA फ़ंक्शन बनाते हैं जो UCase() . का अनुकरण करता है समारोह:
 
पब्लिक फंक्शन MyUCase(InputValue as variant) स्ट्रिंग के रूप में MyUCase =UCase(InputValue)End Function
 और क्वेरी में फ़िल्टरिंग को इसमें बदल दिया:
 
WHERE MyUCase([c].[CityName])="BOSTON";
 हमें यही मिलता है:
 
SQLExecDirect:"CityName" , "c"।"CityID" "Application" से चुनें। "Cities" "c" 
 एक्सेस कस्टम VBA फ़ंक्शन को दूरस्थ करने में असमर्थ है MyUCase डेटा स्रोत पर वापस। हालाँकि, सहेजी गई क्वेरी का SQL कानूनी है इसलिए एक्सेस को इसे किसी तरह संतुष्ट करना होगा। ऐसा करने के लिए, यह CityName . का पूरा सेट डाउनलोड कर लेता है और इसके संगत CityID VBA फ़ंक्शन में पास करने के लिए MyUCase() और परिणाम का मूल्यांकन करें। नतीजतन, क्वेरी अब बहुत धीमी गति से काम करती है क्योंकि एक्सेस अब अधिक डेटा का अनुरोध कर रहा है और अधिक काम कर रहा है।
 

 हालांकि हमने UCase() . का इस्तेमाल किया इस उदाहरण में, हम स्पष्ट रूप से देख सकते हैं कि डेटा स्रोत के लिए जितना संभव हो उतना काम दूरस्थ रूप से करना बेहतर है। लेकिन क्या होगा अगर हमारे पास एक जटिल VBA फ़ंक्शन है जिसे डेटा स्रोत की मूल SQL बोली में फिर से नहीं लिखा जा सकता है? हालांकि मुझे लगता है कि यह परिदृश्य काफी दुर्लभ है, यह विचार करने योग्य है। मान लीजिए कि हम लौटाए गए शहरों के समूह को कम करने के लिए एक फ़िल्टर जोड़ सकते हैं।
 
चुनें c.CityID ,c.CityName ,c.StateProvinceIDFROM शहरों से जहां c.CityName जैसे "Bos*" और MyUCase([c].[CityName])="BOSTON";
 ट्रेस किया गया ODBC SQL इस तरह से सामने आएगा:
 
SQLExecDirect:"एप्लिकेशन" से "CityName" , "c"।"CityID" चुनें। शहर" "c" WHERE ("CityName" LIKE 'Bos%' ) 
 एक्सेस LIKE . को रिमोट करने में सक्षम है डेटा स्रोत पर वापस, जिसके परिणामस्वरूप बहुत छोटे डेटासेट वापस मिल जाते हैं। यह अभी भी MyUCase() . का स्थानीय मूल्यांकन करेगा परिणामी डेटासेट पर। केवल छोटे डेटासेट के लौटाए जाने के कारण क्वेरी बहुत तेज़ी से चलती है।
 

 यह हमें बताता है कि क्या हम अवांछित परिदृश्य का सामना करते हैं जहां हम एक क्वेरी से जटिल वीबीए फ़ंक्शन को आसानी से दोबारा नहीं कर सकते हैं, फिर भी हम उन फ़िल्टरों को जोड़कर खराब प्रभावों को कम कर सकते हैं जिन्हें काम करने के लिए एक्सेस के प्रारंभिक सेट को कम करने के लिए रिमोट किया जा सकता है। 
 
सरगेबिलिटी पर एक नोट
 

 पिछले उदाहरणों में, हमने एक स्तंभ पर एक अदिश फलन लागू किया था। इसमें क्वेरी को "नॉन-सेर्गेबल" के रूप में प्रस्तुत करने की क्षमता है, जिसका अर्थ है कि डेटाबेस इंजन मिलान खोजने और खोजने के लिए इंडेक्स का उपयोग करके क्वेरी को अनुकूलित करने में असमर्थ है। शब्द "सरगेबिलिटी" का "सरग" भाग "खोज तर्क" को संदर्भित करता है। मान लीजिए कि हमारे पास टेबल पर डेटा स्रोत पर इंडेक्स परिभाषित है:
 
इंडेक्स IX_Cities_CityNameON एप्लिकेशन बनाएं। शहर (CityName);
 अभिव्यक्ति जैसे UCASE(CityName) डेटाबेस इंजन को इंडेक्स IX_Cities_CityName . का उपयोग करने में सक्षम होने से रोकता है क्योंकि इंजन को मिलान खोजने के लिए प्रत्येक पंक्ति का एक-एक करके मूल्यांकन करने के लिए मजबूर किया जाता है, जैसे एक्सेस ने कस्टम वीबीए फ़ंक्शन के साथ किया था। कुछ डेटाबेस इंजन जैसे SQL सर्वर के हाल के संस्करण एक अभिव्यक्ति के आधार पर सूचकांक बनाने का समर्थन करते हैं। अगर हम UCASE() . का उपयोग करके क्वेरी को ऑप्टिमाइज़ करना चाहते हैं लेन-देन-एसक्यूएल फ़ंक्शन, हम सूचकांक परिभाषा को समायोजित कर सकते हैं:
 
इंडेक्स IX_Cities_Boston_UppercaseON एप्लिकेशन बनाएं। शहर (CityName)जहां UCASE(CityName) ='BOSTON';
 यह SQL सर्वर को WHERE UCase(CityName) = 'BOSTON' के साथ क्वेरी का इलाज करने में सक्षम बनाता है एक सुगम क्वेरी के रूप में क्योंकि यह अब IX_Cities_Boston_Uppercase अनुक्रमणिका का उपयोग कर सकती है मिलान रिकॉर्ड वापस करने के लिए। हालांकि, अगर क्वेरी 'CLEVELAND' . पर मेल खाती है 'BOSTON' . के बजाय , सुगमता खो जाती है।
 

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

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

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

 अगले लेख में हम देखेंगे कि एक्सेस द्वारा जॉइन को कैसे हैंडल किया जाता है।
 

 माइक्रोसॉफ्ट एक्सेस के साथ मदद की तलाश है? हमारे विशेषज्ञों को आज ही 773-809-5456 पर कॉल करें या हमें [email protected] पर ईमेल करें।