जब कोई उपयोगकर्ता किसी ODBC लिंक की गई तालिका के डेटा में परिवर्तन करता है तो Access क्या कर रहा होता है?
हमारी ODBC ट्रेसिंग श्रृंखला जारी है, और इस चौथे लेख में हम बताएंगे कि कैसे एक रिकॉर्डसेट में डेटा रिकॉर्ड को सम्मिलित और अद्यतन किया जाए, साथ ही रिकॉर्ड को हटाने की प्रक्रिया भी। पिछले लेख में, हमने सीखा कि कैसे एक्सेस ओडीबीसी स्रोतों से डेटा को पॉप्युलेट करता है। हमने देखा कि ओडीबीसी डेटा स्रोत के लिए एक्सेस कैसे प्रश्नों को तैयार करेगा, इस पर रिकॉर्डसेट प्रकार का महत्वपूर्ण प्रभाव पड़ता है। इससे भी महत्वपूर्ण बात यह है कि हमने पाया कि एक डायनासेट-प्रकार के रिकॉर्डसेट के साथ, एक्सेस एक कुंजी का उपयोग करके एक पंक्ति का चयन करने में सक्षम होने के लिए आवश्यक सभी जानकारी रखने के लिए अतिरिक्त कार्य करता है। यह इस लेख में लागू होगा जहां हम यह पता लगाते हैं कि डेटा संशोधनों को कैसे नियंत्रित किया जाता है। हम सम्मिलन से शुरू करेंगे, जो कि सबसे जटिल ऑपरेशन है, फिर अपडेट और अंत में हटाने के लिए आगे बढ़ें।
रिकॉर्डसेट में रिकॉर्ड डालना
डायनासेट-प्रकार के रिकॉर्डसेट का सम्मिलन व्यवहार इस बात पर निर्भर करेगा कि एक्सेस अंतर्निहित तालिका की कुंजियों को कैसे मानता है। 3 अलग व्यवहार होंगे। पहले दो प्राथमिक कुंजी को संभालने से संबंधित हैं जो सर्वर द्वारा किसी भी तरह से स्वत:उत्पन्न होते हैं। दूसरा पहले व्यवहार का एक विशेष मामला है जो केवल IDENTITY का उपयोग करके SQL सर्वर बैकएंड के साथ लागू होता है कॉलम। अंतिम मामले से संबंधित है जब उपयोगकर्ता द्वारा चाबियाँ प्रदान की जाती हैं (उदाहरण के लिए डेटा प्रविष्टि के हिस्से के रूप में प्राकृतिक कुंजी)। हम सर्वर-जनित कुंजियों के अधिक सामान्य मामले से शुरुआत करेंगे।
एक रिकॉर्ड सम्मिलित करना; सर्वर-जनित प्राथमिक कुंजी वाली तालिका
जब हम एक रिकॉर्डसेट डालते हैं (फिर से, हम इसे कैसे करते हैं, एक्सेस यूआई या वीबीए के माध्यम से कोई फर्क नहीं पड़ता), एक्सेस को स्थानीय कैश में नई पंक्ति जोड़ने के लिए चीजें करनी चाहिए।
ध्यान देने वाली महत्वपूर्ण बात यह है कि कुंजी को कैसे सेट किया जाता है, इसके आधार पर एक्सेस में अलग-अलग सम्मिलित व्यवहार होते हैं। इस मामले में, Cities तालिका में IDENTITY नहीं है विशेषता के बजाय SEQUENCE . का उपयोग करता है एक नई कुंजी उत्पन्न करने के लिए वस्तु। यहाँ स्वरूपित ट्रेस किया गया SQL है:
SQLExecDirect: INSERT INTO "Application"."Cities" ( "CityName" ,"StateProvinceID" ,"LatestRecordedPopulation" ,"LastEditedBy" ) VALUES ( ? ,? ,? ,?) SQLPrepare: SELECT "CityID" ,"CityName" ,"StateProvinceID" ,"Location" ,"LatestRecordedPopulation" ,"LastEditedBy" ,"ValidFrom" ,"ValidTo" FROM "Application"."Cities" WHERE "CityID" IS NULL SQLExecute: (GOTO BOOKMARK) SQLExecDirect: SELECT "Application"."Cities"."CityID" FROM "Application"."Cities" WHERE "CityName" = ? AND "StateProvinceID" = ? AND "LatestRecordedPopulation" = ? AND "LastEditedBy" = ? SQLExecute: (GOTO BOOKMARK) SQLExecute: (MULTI-ROW FETCH)ध्यान दें कि एक्सेस केवल उन कॉलम को सबमिट करेगा जो वास्तव में उपयोगकर्ता द्वारा संशोधित किए गए थे। भले ही क्वेरी में अधिक कॉलम शामिल थे, हमने केवल 4 कॉलम संपादित किए, इसलिए एक्सेस में केवल वे ही शामिल होंगे। यह सुनिश्चित करता है कि एक्सेस अन्य कॉलम के लिए डिफ़ॉल्ट व्यवहार सेट में हस्तक्षेप नहीं करता है जिसे उपयोगकर्ता ने संशोधित नहीं किया है, क्योंकि एक्सेस को इस बारे में कोई विशेष जानकारी नहीं है कि डेटा स्रोत उन कॉलम को कैसे संभालेगा। इसके अलावा, इंसर्ट स्टेटमेंट वह है जिसकी हम अपेक्षा करते हैं।
हालाँकि, दूसरा कथन थोड़ा अजीब है। यह WHERE "CityID" IS NULL . के लिए चयन करता है . यह असंभव लगता है, क्योंकि हम पहले से ही जानते हैं कि CityID कॉलम प्राथमिक कुंजी है और परिभाषा के अनुसार शून्य नहीं हो सकता है। हालाँकि, यदि आप स्क्रीनशॉट को देखें, तो हमने कभी भी CityID . को संशोधित नहीं किया कॉलम। एक्सेस 'पीओवी से, यह NULL है . सबसे अधिक संभावना है, एक्सेस एक निराशावादी दृष्टिकोण अपनाता है और यह नहीं मानेगा कि डेटा स्रोत वास्तव में SQL मानक का पालन करेगा। जैसा कि हमने अनुभाग से चर्चा करते हुए देखा कि कैसे एक्सेस एक पंक्ति को विशिष्ट रूप से पहचानने के लिए उपयोग करने के लिए एक इंडेक्स का चयन करता है, यह प्राथमिक कुंजी नहीं हो सकता है, लेकिन केवल एक UNIQUE हो सकता है अनुक्रमणिका जो NULL . की अनुमति दे सकती है . उस असंभावित किनारे के मामले के लिए, यह केवल यह सुनिश्चित करने के लिए एक प्रश्न करता है कि डेटा स्रोत ने वास्तव में उस मान के साथ एक नया रिकॉर्ड नहीं बनाया है। एक बार जब यह जांच कर लेता है कि कोई डेटा वापस नहीं किया गया है, तो यह निम्न फ़िल्टर के साथ फिर से रिकॉर्ड का पता लगाने की कोशिश करता है:
WHERE "CityName" = ? AND "StateProvinceID" = ? AND "LatestRecordedPopulation" = ? AND "LastEditedBy" = ?जो वही 4 कॉलम थे जिन्हें उपयोगकर्ता ने वास्तव में संशोधित किया था। चूंकि "ज़ेके" नाम का केवल एक शहर था, इसलिए हमें केवल एक रिकॉर्ड वापस मिला, और इस प्रकार एक्सेस स्थानीय कैश को नए रिकॉर्ड के साथ उसी डेटा के साथ पॉप्युलेट कर सकता है जैसा डेटा स्रोत में है। यह
SELECT . के बाद से, अन्य कॉलम में कोई भी बदलाव शामिल करेगा सूची में केवल CityID शामिल है कुंजी, जिसे वह अपने पहले से तैयार कथन में उपयोग करेगा और फिर CityID का उपयोग करके पूरी पंक्ति को पॉप्युलेट करेगा। कुंजी। एक रिकॉर्ड सम्मिलित करना; स्वत:वृद्धिशील प्राथमिक कुंजी वाली तालिका
हालांकि, क्या होगा यदि तालिका SQL सर्वर डेटाबेस से आती है और इसमें IDENTITY जैसे स्वत:वृद्धिशील स्तंभ हैं गुण? एक्सेस अलग तरह से व्यवहार करता है। तो चलिए Cities . की एक कॉपी बनाते हैं तालिका लेकिन संपादित करें ताकि CityID कॉलम अब एक IDENTITY है कॉलम।
आइए देखें कि एक्सेस इसे कैसे हैंडल करता है:
SQLExecDirect: INSERT INTO "Application"."Cities" ( "CityName" ,"StateProvinceID" ,"LatestRecordedPopulation" ,"LastEditedBy" ,"ValidFrom" ,"ValidTo" ) VALUES ( ? ,? ,? ,? ,? ,?) SQLExecDirect: SELECT @@IDENTITY SQLExecute: (GOTO BOOKMARK) SQLExecute: (GOTO BOOKMARK)काफी कम बकबक है; हम बस एक
SELECT @@IDENTITY करते हैं नई डाली गई पहचान खोजने के लिए। दुर्भाग्य से, यह एक सामान्य व्यवहार नहीं है। उदाहरण के लिए, MySQL SELECT @@IDENTITY . करने की क्षमता का समर्थन करता है , हालांकि, एक्सेस यह व्यवहार प्रदान नहीं करेगा। PostgreSQL ODBC ड्राइवर के पास @@IDENTITY भेजने के लिए एक्सेस को चकमा देने के लिए SQL सर्वर का अनुकरण करने का एक तरीका है PostgreSQL के लिए ताकि यह समकक्ष serial . पर मैप कर सके डेटा प्रकार। प्राथमिक कुंजी के लिए स्पष्ट मान वाला रिकॉर्ड सम्मिलित करना
आइए सामान्य int . वाली तालिका का उपयोग करके तीसरा प्रयोग करें कॉलम, बिना IDENTITY . के गुण। हालांकि यह अभी भी टेबल पर एक प्राथमिक कुंजी होगी, हम यह देखना चाहेंगे कि जब हम स्पष्ट रूप से स्वयं कुंजी डालते हैं तो यह कैसे व्यवहार करता है।
SQLExecDirect: INSERT INTO "Application"."Cities" ( "CityID" ,"CityName" ,"StateProvinceID" ,"LatestRecordedPopulation" ,"LastEditedBy" ,"ValidFrom" ,"ValidTo" ) VALUES ( ? ,? ,? ,? ,? ,? ,? ) SQLExecute: (GOTO BOOKMARK) SQLExecute: (MULTI-ROW FETCH)इस बार कोई अतिरिक्त जिम्नास्टिक नहीं है; चूंकि हमने पहले ही प्राथमिक कुंजी के लिए मान प्रदान कर दिया है, एक्सेस जानता है कि उसे पंक्ति को फिर से खोजने और खोजने की आवश्यकता नहीं है; यह केवल सम्मिलित पंक्ति को पुन:सिंक्रनाइज़ करने के लिए तैयार कथन निष्पादित करता है। मूल डिज़ाइन पर वापस जा रहे हैं जहाँ
Cities तालिका में SEQUENCE का उपयोग किया गया है एक नई कुंजी उत्पन्न करने के लिए, हम NEXT VALUE FOR का उपयोग करके नया नंबर लाने के लिए VBA फ़ंक्शन जोड़ सकते हैं और इस प्रकार हमें यह व्यवहार प्राप्त करने के लिए कुंजी को सक्रिय रूप से पॉप्युलेट करें। यह अधिक बारीकी से अनुमान लगाता है कि एक्सेस डेटाबेस इंजन कैसे काम करता है; जैसे ही हम किसी रिकॉर्ड को गंदा करते हैं, यह AutoNumber . से एक नई कुंजी प्राप्त करता है डेटा प्रकार, तब तक प्रतीक्षा करने के बजाय जब तक कि रिकॉर्ड वास्तव में सम्मिलित नहीं हो जाता। इस प्रकार, यदि आपका डेटाबेस SEQUENCE . का उपयोग करता है या कुंजियाँ बनाने के अन्य तरीके, यह कुंजी को सक्रिय रूप से लाने का एक तंत्र प्रदान करने के लिए भुगतान कर सकता है ताकि अनुमान लगाने में मदद मिल सके कि हमने एक्सेस को पहले उदाहरण के साथ करते हुए देखा था। रिकॉर्डसेट में रिकॉर्ड अपडेट करना
पिछले अनुभाग में सम्मिलित करने के विपरीत, अपडेट अपेक्षाकृत आसान हैं क्योंकि हमारे पास पहले से ही कुंजी मौजूद है। इस प्रकार, जब अपडेट की बात आती है तो एक्सेस आमतौर पर अधिक सीधा व्यवहार करता है। रिकॉर्ड को अपडेट करते समय हमें दो प्रमुख व्यवहारों पर विचार करने की आवश्यकता होती है जो एक पंक्ति संस्करण कॉलम की उपस्थिति पर निर्भर करता है।
पंक्ति संस्करण कॉलम के बिना रिकॉर्ड अपडेट करना
मान लीजिए कि हम केवल एक कॉलम को संशोधित करते हैं। ओडीबीसी में हम यही देखते हैं।
SQLExecute: (GOTO BOOKMARK) SQLExecDirect: UPDATE "Application"."Cities" SET "CityName"=? WHERE "CityID" = ? AND "CityName" = ? AND "StateProvinceID" = ? AND "Location" IS NULL AND "LatestRecordedPopulation" = ? AND "LastEditedBy" = ? AND "ValidFrom" = ? AND "ValidTo" = ?हम्म, उन सभी अतिरिक्त स्तंभों का क्या संबंध है जिन्हें हमने संशोधित नहीं किया? खैर, फिर से, एक्सेस को निराशावादी दृष्टिकोण अपनाना होगा। यह मान लेना चाहिए कि कोई संभवतः डेटा बदल सकता था, जबकि उपयोगकर्ता धीरे-धीरे संपादन के माध्यम से लड़खड़ा रहा था। लेकिन एक्सेस को कैसे पता चलेगा कि किसी और ने सर्वर पर डेटा बदल दिया है? ठीक है, तार्किक रूप से, यदि सभी कॉलम बिल्कुल समान हैं, तो उसे केवल एक पंक्ति अपडेट करनी चाहिए थी, है ना? जब एक्सेस सभी स्तंभों की तुलना करता है, तो वह यही खोज रहा है; यह सुनिश्चित करने के लिए कि अद्यतन केवल एक पंक्ति को प्रभावित करेगा। यदि यह पाता है कि उसने एक से अधिक पंक्तियों या शून्य पंक्तियों को अपडेट किया है, तो यह अपडेट को रोलबैक करता है और या तो एक त्रुटि या
#Deleted लौटाता है उपयोगकर्ता के लिए। लेकिन ... यह अक्षम्य है, है ना? इसके अलावा, यह समस्या ला सकता है यदि सर्वर-साइड लॉजिक है जो उपयोगकर्ता द्वारा मान इनपुट को बदल सकता है। उदाहरण के लिए, मान लीजिए कि हम एक मूर्खतापूर्ण ट्रिगर जोड़ते हैं जो शहर का नाम बदल देता है (हम निश्चित रूप से इसकी अनुशंसा नहीं करते हैं):
CREATE TRIGGER SillyTrigger
ON Application.Cities AFTER UPDATE AS
BEGIN
UPDATE Application.Cities
SET CityName = 'zzzzz'
WHERE EXISTS (
SELECT NULL
FROM inserted AS i
WHERE Cities.CityID = i.CityID
);
END; इसलिए यदि हम शहर का नाम बदलकर एक पंक्ति को अपडेट करने का प्रयास करते हैं, तो ऐसा लगता है कि यह सफल हो गया है।
लेकिन अगर हम इसे फिर से संपादित करने का प्रयास करते हैं, तो हमें ताज़ा संदेश के साथ एक त्रुटि संदेश मिलता है:
यह sqlout.txt से आउटपुट है :
SQLExecDirect: UPDATE "Application"."Cities" SET "CityName"=? WHERE "CityID" = ? AND "CityName" = ? AND "StateProvinceID" = ? AND "Location" IS NULL AND "LatestRecordedPopulation" = ? AND "LastEditedBy" = ? AND "ValidFrom" = ? AND "ValidTo" = ? SQLExecute: (GOTO BOOKMARK) SQLExecute: (GOTO BOOKMARK) SQLExecute: (MULTI-ROW FETCH) SQLExecute: (MULTI-ROW FETCH)यह नोट करना महत्वपूर्ण है कि दूसरा
GOTO BOOKMARK और बाद में MULTI-ROW FETCH es तब तक नहीं हुआ जब तक हमें त्रुटि संदेश नहीं मिला और इसे खारिज कर दिया। इसका कारण यह है कि जैसे ही हम किसी रिकॉर्ड को गंदा करते हैं, एक्सेस एक GOTO BOOKMARK करता है , महसूस करें कि लौटाया गया डेटा अब कैश में मौजूद डेटा से मेल नहीं खाता है, जिसके कारण हमें "डेटा बदल दिया गया है" संदेश प्राप्त होता है। यह हमें उस रिकॉर्ड को संपादित करने में समय बर्बाद करने से रोकता है जो विफल होने के लिए अभिशप्त है क्योंकि यह पहले से ही बासी है। ध्यान दें कि यदि हम डेटा को रीफ्रेश करने के लिए पर्याप्त समय देते हैं तो एक्सेस अंततः परिवर्तन की खोज करेगा। उस स्थिति में, कोई त्रुटि संदेश नहीं होगा; डेटाशीट को केवल सही डेटा दिखाने के लिए अपडेट किया जाएगा।
उन मामलों में, हालांकि, एक्सेस के पास सही कुंजी थी इसलिए नए डेटा की खोज में कोई समस्या नहीं थी। लेकिन अगर यह कुंजी नाजुक है? यदि ट्रिगर ने प्राथमिक कुंजी को बदल दिया था या ODBC डेटा स्रोत उस मान का प्रतिनिधित्व नहीं करता था जैसा कि एक्सेस ने सोचा था, तो इससे एक्सेस रिकॉर्ड को #Deleted के रूप में रंग देगा। चूंकि यह नहीं जान सकता कि इसे सर्वर द्वारा संपादित किया गया था या किसी और ने बनाम यदि इसे वैध रूप से किसी और द्वारा हटा दिया गया था।
पंक्ति संस्करण कॉलम के साथ रिकॉर्ड अपडेट करना
किसी भी तरह से, त्रुटि संदेश प्राप्त करना या #Deleted काफी परेशान कर सकता है। लेकिन सभी स्तंभों की तुलना करने से एक्सेस से बचने का एक तरीका है। आइए ट्रिगर को हटा दें और एक नया कॉलम जोड़ें:
ALTER TABLE Application.Cities ADD RV rowversion NOT NULL;हम एक
rowversion add जोड़ते हैं जिसमें SQLSpecialColumns(SQL_ROWVER) होने के कारण ODBC के संपर्क में आने का गुण है , जो कि एक्सेस को यह जानने की जरूरत है कि इसका उपयोग पंक्ति को संस्करणित करने के तरीके के रूप में किया जा सकता है। आइए देखें कि इस बदलाव के साथ अपडेट कैसे काम करते हैं। SQLExecDirect: UPDATE "Application"."Cities" SET "CityName"=? WHERE "CityID" = ? AND "RV" = ? SQLExecute: (GOTO BOOKMARK)पिछले उदाहरण के विपरीत जहां एक्सेस ने प्रत्येक कॉलम में मान की तुलना की, चाहे उपयोगकर्ता ने इसे संपादित किया हो या नहीं, हम केवल
RV का उपयोग करके रिकॉर्ड को अपडेट करते हैं। फ़िल्टर मानदंड के रूप में। तर्क यह है कि यदि RV अभी भी वही मान है जो एक्सेस में पास हुआ था, फिर एक्सेस आश्वस्त हो सकता है कि यह पंक्ति किसी और द्वारा संपादित नहीं की गई थी क्योंकि अगर यह था, तो RV का मान बदल गया होता। इसका यह भी अर्थ है कि यदि कोई ट्रिगर डेटा को बदल देता है या यदि SQL सर्वर और एक्सेस बिल्कुल एक ही तरह से एक मान का प्रतिनिधित्व नहीं करते हैं (जैसे फ्लोटिंग नंबर), तो अपडेट की गई पंक्ति को फिर से चुनने पर एक्सेस बंद नहीं होगा और यह अलग-अलग के साथ वापस आता है अन्य कॉलम में मान जिन्हें उपयोगकर्ताओं ने संपादित नहीं किया।
नोट :सभी DBMS उत्पाद समान शर्तों का उपयोग नहीं करेंगे। उदाहरण के तौर पर, MySQL का timestamp ओडीबीसी के उद्देश्यों के लिए एक पंक्ति संस्करण के रूप में इस्तेमाल किया जा सकता है। यह देखने के लिए कि क्या वे पंक्ति संस्करण सुविधा का समर्थन करते हैं, आपको उत्पाद के दस्तावेज़ीकरण से परामर्श करना होगा ताकि आप एक्सेस के साथ इस व्यवहार का लाभ उठा सकें।
दृश्य और पंक्ति संस्करण
दृश्य एक पंक्ति संस्करण की उपस्थिति या अनुपस्थिति से भी प्रभावित होते हैं। मान लीजिए कि हम परिभाषा के साथ SQL सर्वर में एक दृश्य बनाते हैं:
CREATE VIEW dbo.vwCities AS SELECT CityID, CityName FROM Application.Cities;दृश्य पर किसी रिकॉर्ड को अपडेट करने से स्तंभ-दर-स्तंभ तुलना पर वापस आ जाएगा जैसे कि पंक्ति संस्करण स्तंभ तालिका पर मौजूद नहीं था:
SQLExecDirect: UPDATE "dbo"."vwCities" SET "CityName"=? WHERE "CityID" = ? AND "CityName" = ?इसलिए, यदि आपको पंक्ति-संस्करण-आधारित अद्यतन व्यवहार की आवश्यकता है, तो आपको यह सुनिश्चित करने के लिए ध्यान रखना चाहिए कि पंक्ति-संस्करण कॉलम दृश्यों में शामिल हैं। ऐसे दृश्य के मामले में जिसमें जॉइन में कई टेबल हैं, जहां आप अपडेट करना चाहते हैं, वहां टेबल से कम से कम रोवर्सन कॉलम शामिल करना सबसे अच्छा है। क्योंकि आम तौर पर केवल एक तालिका को अपडेट किया जा सकता है, जिसमें सामान्य नियम के रूप में केवल एक पंक्ति संस्करण पर्याप्त हो सकता है।
रिकॉर्डसेट में रिकॉर्ड हटाना
किसी रिकॉर्ड को हटाना अपडेट के समान व्यवहार करता है और यदि उपलब्ध हो तो पंक्ति संस्करण का भी उपयोग करेगा। बिना पंक्ति के एक टेबल पर, हमें मिलता है:
SQLExecDirect: DELETE FROM "Application"."Cities" WHERE "CityID" = ? AND "CityName" = ? AND "StateProvinceID" = ? AND "Location" IS NULL AND "LatestRecordedPopulation" = ? AND "LastEditedBy" = ? AND "ValidFrom" = ? AND "ValidTo" = ?एक पंक्ति संस्करण के साथ एक मेज पर, हम प्राप्त करते हैं:
SQLExecDirect: DELETE FROM "Application"."Cities" WHERE "CityID" = ? AND "RV" = ?फिर से, एक्सेस को हटाने के बारे में निराशावादी होना चाहिए क्योंकि यह अद्यतन करने के बारे में है; यह उस पंक्ति को हटाना नहीं चाहेगा जिसे किसी और ने बदल दिया था। इस प्रकार यह उसी व्यवहार का उपयोग करता है जिसे हमने एक ही रिकॉर्ड को बदलने वाले एकाधिक उपयोगकर्ताओं के खिलाफ सुरक्षा के लिए अद्यतन के साथ देखा था।
निष्कर्ष
हमने सीखा है कि कैसे एक्सेस डेटा संशोधनों को संभालता है और ओडीबीसी डेटा स्रोत के साथ अपने स्थानीय कैश को सिंक्रनाइज़ेशन में रखता है। हमने देखा कि कैसे निराशावादी पहुंच थी, जो विशिष्ट धारणाओं या अपेक्षाओं पर भरोसा किए बिना अधिक से अधिक ओडीबीसी डेटा स्रोतों का समर्थन करने की आवश्यकता से प्रेरित थी कि ऐसे ओडीबीसी डेटा स्रोत एक निश्चित सुविधा का समर्थन करेंगे। इस कारण से, हमने देखा कि किसी दिए गए ओडीबीसी लिंक्ड टेबल के लिए कुंजी को कैसे परिभाषित किया जाता है, इस पर निर्भर करता है कि एक्सेस अलग-अलग व्यवहार करेगा। यदि हम एक नई कुंजी को स्पष्ट रूप से सम्मिलित करने में सक्षम थे, तो इसके लिए एक्सेस से न्यूनतम कार्य की आवश्यकता थी ताकि नए सम्मिलित रिकॉर्ड के लिए स्थानीय कैश को फिर से सिंक्रनाइज़ किया जा सके। हालांकि, अगर हम सर्वर को कुंजी को पॉप्युलेट करने की अनुमति देते हैं, तो एक्सेस को फिर से सिंक्रनाइज़ करने के लिए पृष्ठभूमि में अतिरिक्त काम करना होगा।
हमने यह भी देखा कि टेबल पर एक कॉलम होने से जिसे एक पंक्ति संस्करण के रूप में इस्तेमाल किया जा सकता है, एक अपडेट पर एक्सेस और ओडीबीसी डेटा स्रोत के बीच बातचीत को कम करने में मदद कर सकता है। आपको यह निर्धारित करने के लिए ODBC ड्राइवर दस्तावेज़ से परामर्श करना होगा कि क्या यह ODBC परत पर पंक्ति-संस्करण का समर्थन करता है और यदि ऐसा है, तो पंक्ति-आधारित अद्यतनों के लाभों को प्राप्त करने के लिए एक्सेस से लिंक करने से पहले ऐसे कॉलम को तालिकाओं या दृश्यों में शामिल करें।
अब हम जानते हैं कि किसी भी अपडेट या हटाने के लिए, एक्सेस हमेशा यह सत्यापित करने का प्रयास करेगा कि पंक्ति को नहीं बदला गया था क्योंकि इसे अंतिम बार एक्सेस द्वारा लाया गया था, ताकि उपयोगकर्ताओं को अप्रत्याशित परिवर्तन करने से रोका जा सके। हालांकि, हमें अन्य स्थानों में परिवर्तन करने से उत्पन्न होने वाले प्रभावों पर विचार करने की आवश्यकता है (उदाहरण के लिए सर्वर-साइड ट्रिगर, किसी अन्य कनेक्शन में एक अलग क्वेरी चलाना) जो एक्सेस को यह निष्कर्ष निकालने का कारण बन सकता है कि पंक्ति बदल दी गई थी और इस प्रकार परिवर्तन को अस्वीकार कर दिया गया था। वह जानकारी हमें विश्लेषण करने और डेटा संशोधनों का एक क्रम बनाने से बचने में मदद करेगी जो स्थानीय कैश को पुन:सिंक्रनाइज़ करते समय एक्सेस की अपेक्षाओं के विपरीत हो सकता है।
अगले लेख में, हम एक रिकॉर्डसेट पर फ़िल्टर लगाने के प्रभावों को देखेंगे।
आज ही हमारे एक्सेस विशेषज्ञों से सहायता प्राप्त करें। हमारी टीम को 773-809-5456 पर कॉल करें या हमें [email protected] पर ईमेल करें।
