रिकॉर्डसेट में शामिल होने का प्रभाव
ओडीबीसी ट्रेसिंग श्रृंखला के हमारे छठे और अंतिम लेख में, हम इस पर एक नज़र डालने जा रहे हैं कि एक्सेस क्वेरीज़ में एक्सेस कैसे शामिल होगा। पिछले लेख में, आपने देखा था कि एक्सेस द्वारा फ़िल्टर कैसे प्रबंधित किए जाते हैं। अभिव्यक्ति के आधार पर, एक्सेस इसे दूर पैरामीटर करना चुन सकता है या सभी इनपुट डेटा को डाउनलोड करके स्थानीय स्तर पर मूल्यांकन करके इसका मूल्यांकन करने के लिए मजबूर किया जा सकता है। इस लेख में, हम जुड़ने पर ध्यान केंद्रित करेंगे। जब आप इसके बारे में सोचते हैं, तो जुड़ना वास्तव में एक विशेष प्रकार का फ़िल्टर होता है। इसलिए, सिद्धांत रूप में, एक्सेस को जॉइन के साथ जितना संभव हो उतना रिमोट करना चाहिए। आप आमतौर पर निम्नलिखित छद्म-एसक्यूएल में लिखे हुए जोड़ देख सकते हैं:
इनर से a.ID =b.ID पर शामिल होंहालांकि, इसे निम्नलिखित सिंटैक्स के बराबर माना जा सकता है:
FROM a, b जहां a.ID =b.IDयह दर्शाता है कि भले ही हम अधिक पठनीय और परिचित
JOIN..ON . का उपयोग कर सकते हैं , इसे WHERE . के रूप में मानने के लिए एक्सेस मुफ़्त है जो उन स्थितियों में मददगार है जहां एक्सेस क्वेरी को पूरी तरह से रिमोट नहीं कर सकता है। लेकिन यहाँ रगड़ है ... एक्सेस कब शामिल होने को दूरस्थ करने का निर्णय लेता है? आइए एक आसान जॉइन क्वेरी का प्रयास करें: चुनें c.CityID ,c.StateProvinceID ,c.CityName ,s.StateProvinceNameसी के रूप में शहरों से C.StateProvinceID =s.StateProvinceID;यदि हम उस क्वेरी का पता लगाते हैं, तो हम निम्न आउटपुट देखेंगे:
SQLExecDirect:"c" चुनें। StateProvinceID" ="s"।" StateProvinceID") SQLPrepare:"Application" से "CityID", "CityName", "StateProvinceID" चुनें। "एप्लिकेशन" से "," StateProvinceName "।" StateProvince" जहां "StateProvinceID" =?SQLExecute:(GOTO BOOKMARK)SQLPrepare:"Application" से "StateProvinceID", "StateProvinceName" चुनें। या "स्टेटप्रोविंसआईडी" =? या "स्टेटप्रोविंसआईडी" =? या "स्टेटप्रोविंसआईडी" =? या "स्टेटप्रोविंसआईडी" =? या "स्टेटप्रोविंसआईडी" =? या "स्टेटप्रोविंसआईडी" =? या "स्टेटप्रोविंसआईडी" =? या "स्टेटप्रोविंसआईडी" =? या "StateProvinceID" =?SQLExecute:(MULTI-ROW FETCH)SQLPrepare:"Application" से "CityID", "CityName", "StateProvinceID" चुनें। या "सिटीआईडी" =? या "सिटीआईडी" =? या "सिटीआईडी" =? या "सिटीआईडी" =? या "सिटीआईडी" =? या "सिटीआईडी" =? या "सिटीआईडी" =? या "सिटीआईडी" =? या "सिटीआईडी" =? SQLExecute:(बहु-पंक्ति फ़ेच) SQLExecute:(बहु-पंक्ति फ़ेच) SQLExecute:(बहु-पंक्ति फ़ेच) SQLExecute:(बहु-पंक्ति फ़ेच) SQLExecute:(बहु-पंक्ति फ़ेच) SQLExecute:(बहु-पंक्ति फ़ेच) SQLExecute:(बहु-पंक्ति फ़ेच) SQLExecute:-रो फ़ेच) SQLExecute:(बहु-पंक्ति फ़ेच) SQLExecute:(बहु-पंक्ति फ़ेच) SQLExecute:(बहु-पंक्ति फ़ेच)एक्सेस ने शामिल होने को दूरस्थ नहीं करने का निर्णय लिया, भले ही मूल एक्सेस क्वेरी SQL सर्वर पर निष्पादित होने में पूरी तरह सक्षम है। इसके बजाय, यह थीटा-जॉइन में प्रत्येक तालिका से आईडी प्राप्त करता है, फिर प्रश्नों की 2 अलग-अलग श्रृंखलाएं सेट करता है जैसे कि हमने 2 डायनासेट-प्रकार के रिकॉर्डसेट खोले थे। दो अलग-अलग तैयार किए गए प्रश्नों को फिर पहली क्वेरी से संबंधित तालिकाओं के लिए कुंजियों को खिलाया जाता है। अनुमानतः, नेटवर्क पर जाने के लिए यह बहुत बकवास हो सकता है।
यदि हम उसी एक्सेस क्वेरी को डिफ़ॉल्ट डायनासेट-प्रकार के बजाय स्नैपशॉट-प्रकार के रूप में बदलते हैं, तो हम प्राप्त करते हैं:
SQLExecDirect:"c" चुनें। एप्लिकेशन"।"राज्य प्रांत" "एस" जहां ("सी"।" StateProvinceID" ="s"।"StateProvinceID") तो स्नैपशॉट-प्रकार की क्वेरी के मामले में एक्सेस रिमोट जॉइन को ठीक करता है। एक्सेस ने मूल डायनासेट-प्रकार की क्वेरी के साथ ऐसा क्यों नहीं किया? सुराग निम्नलिखित स्क्रीनशॉट में है जहां हम दोनों को संपादित करने का प्रयास करते हैं नीचे दिए गए स्क्रीनशॉट में टेबल के कॉलम:
ऐसी क्वेरी दोनों स्तंभों को अद्यतन करने की अनुमति देती है। यह वास्तव में SQL में स्पष्ट नहीं है लेकिन उपयोगकर्ता के लिए ऐसी कार्रवाई कानूनी है। इसलिए, उस अद्यतन को निष्पादित करने के लिए, एक्सेस निम्नलिखित ODBC SQL सबमिट करेगा:
SQLExecDirect:अद्यतन "आवेदन"।"राज्य प्रांत"सेट"StateProvinceName"=? जहां "राज्य प्रांत आईडी" =? और "StateProvinceName" =?SQLExecDirect:अद्यतन "आवेदन"।"शहर"सेट "CityName"=? जहां "सिटीआईडी" =? और "शहर का नाम" =? और "StateProvinceID" =?यह संभव नहीं होगा यदि एक्सेस के पास प्रत्येक तालिका को अद्यतन करने के लिए आवश्यक जानकारी नहीं है, जो बताती है कि मूल डायनासेट-प्रकार की क्वेरी को हल करते समय एक्सेस ने शामिल होने को दूरस्थ रूप से क्यों नहीं चुना। यहां सबक यह है कि यदि आपको अद्यतन करने योग्य क्वेरी की आवश्यकता नहीं है, और परिणामी डेटा काफी छोटा है, तो क्वेरी को स्नैपशॉट प्रकार में परिवर्तित करना बेहतर हो सकता है। उस मामले में जहां आपको एक जटिल रिकॉर्ड स्रोत तैयार करने की आवश्यकता होती है, आप आमतौर पर SQL दृश्य का उपयोग करके एक्सेस साइड पर जुड़ने की तुलना में आधार के रूप में बेहतर प्रदर्शन प्राप्त करेंगे।
इसे साबित करने के लिए, हम एक SQL व्यू बनाएंगे और इसे एक्सेस से लिंक करेंगे:
क्रिएट व्यू dbo.vwCitiesAndStates ASSELECT c.CityID ,c.StateProvinceID ,c.CityName ,s.StateProvinceNameFROM एप्लिकेशन। शहरों के रूप में इनर जॉइन एप्लिकेशन। स्टेटप्रोविंस एएस ऑन सी। फिर हम एक्सेस क्वेरी को निम्नानुसार समायोजित करते हैं:c.CityID ,c.StateProvinceID ,c.CityName ,c.StateProvinceNameFROM vwCitiesAndStates से c चुनें;यदि हम उस अपडेट को दोहराते हैं जिसे हमने मूल रूप से आजमाया था, तो हमें निम्नलिखित ट्रेस किए गए ODBC SQL को देखना चाहिए:SQLExecDirect:"dbo" से "c" "CityID" चुनें। जहां "CityID" =?SQLExecute:(GOTO BOOKMARK)SQLPrepare:चुनें "CityID", "StateProvinceID", "CityName", "StateProvinceName" "dbo" से।vwCitiesAndStates" जहां "CityID" =? या "सिटीआईडी" =? या "सिटीआईडी" =? या "सिटीआईडी" =? या "सिटीआईडी" =? या "सिटीआईडी" =? या "सिटीआईडी" =? या "सिटीआईडी" =? या "सिटीआईडी" =? या "सिटीआईडी" =? SQLExecute:(बहु-पंक्ति फ़ेच) SQLExecute:(बहु-पंक्ति फ़ेच) SQLExecute:(बहु-पंक्ति फ़ेच) SQLExecute:(बहु-पंक्ति फ़ेच) SQLExecute:(बहु-पंक्ति फ़ेच) बुकमार्क) SQLExecDirect:अद्यतन "dbo"।"vwCitiesAndStates" SET "CityName"=?, "StateProvinceName"=? जहां "सिटीआईडी" =? और "स्टेटप्रोविंसआईडी" =? और "शहर का नाम" =? और "StateProvinceName" =?यह दर्शाता है कि जॉइन को "रिमोट" करने के लिए SQL व्यू का उपयोग करते हुए, एक्सेस केवल एक स्रोत के साथ काम करेगा, न कि 2 टेबल के साथ और पूरी तरह से SQL सर्वर पर अपडेट को रिमोट से देखें। एक साइड इफेक्ट यह है कि यह अपडेट अब त्रुटि संदेश के साथ विफल हो जाएगा:
यह कोई आश्चर्य की बात नहीं है क्योंकि हम एक
UPDATEकर रहे थे। एक स्रोत पर जबकि मूल उदाहरण में, एक्सेस वास्तव में गुप्त रूप से दो जारी कर रहा था अलगUPDATEप्रत्येक व्यक्तिगत तालिका पर बयान। उम्मीद है कि यह मामला बनाने में मदद करता है कि आपको एक्सेस क्वेरी/रिकॉर्ड स्रोत/पंक्ति स्रोतों में शामिल होने से बचना चाहिए, खासकर जब उन्हें अद्यतन करने की आवश्यकता होती है। यदि वे नहीं करते हैं, तो जहां संभव हो, स्नैपशॉट का उपयोग करें।विषम जोड़ के बारे में एक त्वरित नोट
हमें दो अलग-अलग ODBC डेटा स्रोतों से आने वाली दो लिंक की गई तालिकाओं के बीच जुड़ने के बारे में टिप्पणी करने की आवश्यकता है। इस तरह के जोड़ "विषम" हैं क्योंकि एक्सेस को स्थानीय रूप से जुड़ने को संभालना चाहिए क्योंकि प्रत्येक डेटा स्रोत को एक दूसरे के बारे में नहीं पता माना जाता है। भले ही आप एक डायनासेट-प्रकार या स्नैपशॉट-प्रकार के रिकॉर्डसेट निर्दिष्ट करें, एक्सेस को प्रत्येक डेटा स्रोत से चाबियों का पूरा सेट प्राप्त करना चाहिए और प्रत्येक डेटा स्रोत के लिए अलग-अलग पैरामीटरयुक्त क्वेरी भेजकर जॉइन का समाधान करना चाहिए। अगर अपडेट करने की अनुमति है, तो एक्सेस एक अलग
UPDATEतैयार करेगा प्रत्येक डेटा स्रोत के लिए क्वेरी जिसे अद्यतन करने की आवश्यकता है। यह भी ध्यान रखना महत्वपूर्ण है कि दो अलग-अलग डेटाबेस से आने वाली दो लिंक की गई तालिकाओं के बीच एक जुड़ाव को अभी भी एक्सेस द्वारा विषम माना जाता है। यह अभी भी सही है, भले ही दो डेटाबेस एक ही सर्वर पर हों और आपको क्रॉस डेटाबेस क्वेरी करने में कोई समस्या न हो। इस परिदृश्य में, एक SQL दृश्य क्रॉस डेटाबेस जॉइन को एक्सेस से छिपाकर अतिरिक्त बकवास पर कटौती करने में मदद कर सकता है, जैसा कि हमने पहले ही इस आलेख में देखा था।बाहरी जुड़ाव सिंटैक्स अंतर
जब तक बाहरी जॉइन एक्सेस क्वेरी की अद्यतनता को प्रभावित नहीं करते हैं, एक्सेस इसे उसी तरह से हैंडल करेगा जैसे उसने इनर जॉइन वर्जन को कैसे हैंडल किया। यदि हम उसी क्वेरी को संशोधित करते हैं जिसे हम लेफ्ट जॉइन करते थे, तो ट्रेस किया गया ODBC SQL प्रमुख जनसंख्या क्वेरी को आउटपुट करेगा जैसे:
SQLExecDirect:"c" चुनें। c"।"StateProvinceID" ="s"।"StateProvinceID") }सिंटैक्स अन्य SQL बोलियों में आप जो अपेक्षा कर सकते हैं उससे काफी अलग दिखता है। ऐसा इसलिए है क्योंकि ODBC SQL व्याकरण के लिए आवश्यक है कि किसी भी बाहरी जोड़ को{oj ...}में लपेटा जाए अभिव्यक्ति। उस सिंटैक्स के बारे में अधिक जानकारी के लिए, दस्तावेज़ीकरण देखें। हमारे उद्देश्य के लिए, हम केवल{oj. की अवहेलना कर सकते हैं और समापन}शोर के रूप में।निष्कर्ष
हमने देखा कि जॉइन के साथ ऐसा व्यवहार किया जाता है जैसे कि वे एक तरह के फिल्टर हों और एक्सेस उन जॉइन को रिमोट करने की कोशिश करेगा जहां इसकी अनुमति है। ध्यान देने के लिए एक विशेष क्षेत्र यह तथ्य है कि डिफ़ॉल्ट रूप से हम डायनासेट प्रकार के रिकॉर्डसेट का उपयोग करते हैं और एक्सेस इस बारे में कोई धारणा नहीं बनाएगा कि क्या हम रिकॉर्डसेट में ऐसे और इतने कॉलम को संशोधित करने की अनुमति देना चाहते हैं और इसे हमारे लिए संभव बनाने के लिए बाहर जाते हैं दो तालिकाओं को अद्यतन करने के लिए जो वास्तव में मानक SQL में आसानी से व्यक्त नहीं की जाती हैं। परिणामस्वरूप, एक्सेस उस क्वेरी के लिए अद्यतन योग्यता का समर्थन करने के लिए बहुत अधिक काम करेगा जिसमें शामिल हैं जो प्रदर्शन को नकारात्मक रूप से प्रभावित कर सकते हैं।
हम एक्सेस क्वेरी में व्यक्त जॉइन के स्थान पर SQL व्यू का उपयोग करके पेनल्टी से बचने में मदद कर सकते हैं। ट्रेडऑफ़ यह है कि हम तब SQL दृश्य के अद्यतन योग्यता नियमों के अधीन होते हैं; हमें एक ही समय में दो तालिकाओं को अद्यतन करने की अनुमति नहीं दी जा सकती है। आमतौर पर क्योंकि एक अच्छी तरह से डिज़ाइन किया गया एक्सेस फ़ॉर्म अपडेट करने के लिए केवल एक तालिका का प्रतिनिधित्व करेगा, यह बहुत अधिक प्रतिबंध नहीं है और पालन करने के लिए एक अच्छा अनुशासन है।
इसके साथ ही मौजूदा सीरीज पूरी हो गई है। हालाँकि, यह सीखना कि श्रृंखला उम्मीद से जगमगाती है, ऐसा नहीं किया जाना चाहिए। मुझे पूरी उम्मीद है कि आपने श्रृंखला को उपयोगी पाया है और ओडीबीसी डेटा स्रोतों का उपयोग करके एक्सेस एप्लिकेशन के साथ प्रदर्शन समस्याओं का विश्लेषण और समाधान करने में सहायता के लिए टूल का उपयोग करने से प्राप्त नई अंतर्दृष्टि के बारे में सुनने के लिए उत्सुक हैं। बेझिझक टिप्पणी छोड़ें या अधिक जानकारी के लिए अनुरोध करें और साथ में पढ़ने के लिए धन्यवाद!
Microsoft Access से संबंधित किसी भी चीज़ में और सहायता के लिए, हमारे विशेषज्ञों को 773-809-5456 पर कॉल करें या हमें [email protected] पर ईमेल करें।
