Data Updating – ADO.NET Objects

Data Updating: Database को Update करना किसी भी Database Application के विभिन्न सबसे जरूरी कामों में से एक होता है। क्योंकि Underlying Data Source में Data को फिर से Update करने के लिए हमें विभिन्न प्रकार के जरूरी Decisions लेने पडते हैं, ताकि Database के Data की Concurrency Support, Performance व Accuracy बनी रहे। इसलिए Data Updating किसी भी Database Application का सबसे Typical Task भी होता है।

Database की किसी Table के Data को Update करने लिए भी हमारे पास दो तरीके होते हैं। पहले तरीके के अन्तर्गत हम चाहें तो Visual Studio द्वारा Provided Drag-and-Drop Technique का प्रयोग कर सकते हैं, जबकि दूसरे तरीके के अन्तर्गत हम Manual Codes लिखते हैं। हालांकि जब हम Drag-and-Drop तरीके का प्रयोग करते हैं, तब भी बहुत सारे Invisible Codes Create होते हैं, लेकिन उन Codes को हमारे लिए स्वयं Visual Studio Create करता है।

Updating Table : Drag-and-Drop Approach

जब हम Underlying Data Source की Tables के Data को Visual Studio का प्रयोग करते हुए Update करना चाहते हैं, तो इस जरूरत को पूरा करने के लिए हमारे पास कई तरीके होते हैं और हम अलग-अलग तरह की जरूरत के आधार पर अलग-अलग तरीके को उपयोग में लेकर Underlying Data Tables के Data को Update कर सकते हैं।

उदाहरण के लिए हम Visual Studio द्वारा Provided Strongly Typed DataSet Object का प्रयोग करते हुए भी Underlying Database की Tables के Data को Update कर सकते हैं, जबकि ADO.NET द्वारा Provided DataSet Object का प्रयोग करते हुए भी इसी जरूरत को पूरा कर सकते हैं।

साथ ही यदि हम चाहें तो DataReader Object का प्रयोग करते हुए भी समान Requirements को पूरा कर सकते हैं, जबकि यदि हम चाहें तो Visual Studio के Wizard Generated Codes के माध्‍यम से Drag-and-Drop तकनीक का प्रयोग करते हुए भी उन्हीं समान जरूरतों को Rapid तरीके से पूरा कर सकते हैं, जिन्हें हम Manual Coding द्वारा पूरा कर सकते हैं।

हम किस तरीके का प्रयोग करते हैं, ये बात पूरी तरह से हमारी जरूरत पर निर्भर करता है। इसलिए जरूरी व बेहतर यही होता है कि हम एक ही काम को करने के विभिन्न तरीकों के बारे में ज्यादा से ज्यादा जानें, ताकि जब जैसी जरूरत हो, उस जरूरत को पूरा करने के लिए Best तरीके का चयन कर सकें।

जब हम Visual Studio के Drag-and-Drop तकनीक का प्रयोग करते हुए Underlying Database की Table के Data को Update करना चाहते हैं, तब सबसे पहले हमें एक Windows Form Application Project करना होता है।

नया Windows Forms Application Project Create करने के बाद हमें VIEW => Other Windows => Data Source Option को Click करके नया Data Source Object Create करना होता है।

चूंकि, नया Data Source Object Create करने के विषय में हमने पहले भी Discuss किया है, इसलिए हम उस Process को यहां पर Repeat नहीं कर रहे हैं। लेकिन इस बार हम Northwind Database के लिए Data Source Create कर रहे हैं और हमारे DataSource के DataSet Object में इस बार Northwind Database की Customers, Products, Orders व Order Details Table के Data DataTable Objects के रूप में Exist हैं।

परिणामस्वरूप इस बार हमें हमारा Data Sources Window Visual Studio के Window के रूप में निम्न चित्रानुसार दिखाई देता है:

Data Source Create कर लेने के बाद उपरोक्त चित्रानुसार दिखाई देने वाले DataSet की Customers Data Table को Drag-and-Drop तकनीक द्वारा Form पर Place करके Fine-Tuning करने के बाद हमें हमारा Form कुछ निम्नानुसार दिखाई देता है:

जैसाकि उपरोक्त चित्र में हम देख सकते हैं कि जब हम Data Sources Window में दिखाई देने वाले DataSet Object में Contained Customers Table को Drag करके Visual Studio में दिखाई देने वाले Form पर Drop करते हैं, तो DataGridView Control के Form पर Place होने के साथ ही हमारे Visual Studio IDE में निम्न चित्रानुसार पांच और नए GUI Controls Add हो जाते हैं, जो कि हमारे Form को बिना किसी तरह का Code लिखे हुए Automatically Working स्थिति में लाने का काम करते हैं:

इसलिए जब हम अपने Current Application को Run करते हैं, तो हमें हमारा Application निम्नानुसार दिखाई देता है:

हम समझ सकते हैं हालांकि इस Application में हमने एक भी Line का Code नहीं लिखा है, फिर भी हमें हमारे Underlying Northwind Database की Customers Table के Data Access होकर DataGridView Control में दिखाई दे रहे हैं। इसे समझने के लिए हमें One-by-One उन सभी Objects को देखना होगा, जो कि उपरोक्तानुसार Steps Follow करने के कारण हमारे Visual Studio में Add हुए हैं।

जब हम उपरोक्तानुसार Steps को Follow करते हुए Application के लिए DataSource Create करते हैं, तो उस DataSet के लिए Create होने वाले DataSet Object को Represent करने के लिए Visual Studio एक .XSD File Create करता है।

हमारे Example में हमने हमारे DataSet Object का नाम dsNW रखा था, इसलिए Visual Studio dsNW.xsd नाम की Strongly Typed DataSet Object File Create करता है, जिसे हम निम्न चित्रानुसार Designer Mode में Visually देख सकते हैं:

यदि हम उपरोक्त चित्र द्वारा ही समझने की कोशिश करें, तो DataSet में Add होने वाली हर DataTable के दो हिस्से हैं, जिसे हम DataTable व DataAdapter के रूप में देख सकते हैं।

उदाहरण के लिए यदि हम Customers Table के लिए Create होने वाले Object को ही देखें, तो इसके “Customers” नाम के DataTable वाले हिस्से के अलावा CustomersTableAdapter नाम का एक और हिस्सा भी है, जो कि DataAdapter Object है। यदि हम इस DataTable पर निम्न चित्रानुसार Mouse से Right Click करें और Display होने वाले Popup Menu से Configure… Option को Click करें-

तो हमारे सामने निम्न चित्रानुसार वह SQL Query Display होता है, जिसके Execute होने के कारण ये DataTable में Data Load होते हैं:

यदि हम चाहें तो अपनी जरूरत के अनुसार इस Query को ;हीं पर Modify भी कर सकते हैं और हम इस Query को जिस तरह से Modify करते हैं, बनने वाली DataTable उसी SQL Query के अनुसार Modify भी हो जाता है। यानी यहां हम Dynamic SQL Query भी Specify कर सकते हैं, जो कि हमारे Application के Runtime में Pass किए गए Parameters के आधार पर Generate होने वाले Resultset से DataSet Object की DataTables को Fill करता है।

इतना ही नहीं, यदि हम इस Dialog Box पर दिखाई देने वाले “Advance Options…” Button को Click करें, तो हमारे सामने निम्नानुसार एक और Dialog Box Display होता है:

इस Dialog Box में हमें तीन Options प्राप्त होते हैं, जिनके माध्‍यम से हम हमारे Visually दिखाई देने वाले DataTable के लिए निम्न बातों को Set कर सकते हैं:

• पहले Checkbox को Select करके हम इस बात को Specify करते हैं कि Visually दिखाई देने वाले DataTable Object के साथ Associated TableAdapter द्वारा हम उस Table में Data को INSERT, UPDATE व DELETE करने की सुविधा प्राप्त करना चाहते हैं।
• दूसरे Checkbox द्वारा हम Concurrently Use होने वाले Database की Concurrency को Control करने की सुविधा प्राप्त करते हैं।
• तीसरे Checkbox को Check करके हम इस बात को Specify करते हैं कि जब Current DataAdapter के माध्‍यम से Underlying DataTable में Data Update हो जाता है, उसके बाद User को जो Data दिखाई देता है, वह Refreshed यानी Updated Data दिखाई देना चाहिए या नहीं। यानी यदि एक ही Table के Data को एक से ज्यादा Users Concurrent तरीके से Use करते हुए Update करते हैं, तो एक User द्वारा किए गए Updated Results, दूसरे User द्वारा Data को उसका Data Update करने के बाद दिखाई देंगे या नहीं।

जैसाकि हम समझ सकते हैं कि पहला Checkbox Select करने पर हमें ये सुविधा प्राप्त होती है कि हम TableAdapter के माध्‍यम से Underlying Data Source को Update कर सकते हैं। जबकि दूसरे व तीसरे Checkbox का सम्बंध हमारे Application के Disconnected Behavior से है, जिन्हें Check करके हम हमारे Application को Concurrency Related Problems को Handle करने के लिए Ensure करते हैं।

उदाहरण के लिए यदि हमारे Application को एक ही समय पर एक से ज्यादा Users Distributed Form में Use कर रहे हों, तो जिस समय हम हमारे DataSet को Underlying DataSource में Stored Data से Fill कर रहे होते हैं, उसी समय कोई अन्य User उसी Data को Change कर रहा हो सकता है।

इस स्थिति में हमारे DataSet में Underlying Database का Old Data ही Disconnected Mode में Available रहेगा, जबकि किसी दूसरे User द्वारा उसी Database के उसी Data को Change किया जा चुका होगा।

इस स्थिति हमें हमारे Application में दूसरे User द्वारा Modify किया गया Data Reflect नहीं होगा, क्योंकि हमें हमारे Application में जो Data दिखाई दे रहा है, वह हमारे DataSet Object में Stored Disconnected Data दिखाई दे रहा होगा, जबकि हमारे DataSet Object में Data आने के बाद दूसरे User ने Data को Modify किया है और हमें तब तक Modified Data प्राप्त नहीं होगा, जब तक कि हम फिर से अपने Application को Underlying DataSource के Database से Connection Open करके Refreshed Data Retrieve न करें। Disconnected Mode में Concurrency की इस स्थिति को समझने के लिए हम एक उदाहरण देखते हैं।

मानलो कि दो Users समान Database के Data को एक ही समय पर Access कर रहे हैं, इस बात को Represent करने के लिए हम हमारे उपरोक्त Form के दो Instances को Run करते हैं:

अब जैसाकि इस चित्र में हम देख सकते हैं, मानलो दोनों ही Users इस Table में एक नया Record Add करते हैं और दोनों ही Add किए जाने वाले Records का Primary Key यानी CustomerID Field में “Kuldeep” ही Input करते हैं। हम यहां ये मान रहे हैं कि Application में सभी User Primary Key का मान स्वयं ही Enter करते हैं और इस स्थिति में ऐसा हो सकता है कि कोई User जो नया Record Add करे, उस Record का Primary Key वही हो, जो कोई दूसरा User अपने Record में Specify कर रहा हो।

चूंकि दोनों ही Users समान Database के Data को Access कर रहे हैं और दोनों ही Users ने जब Underlying Database के Data से अपने DataSet Object को Fill किया, तो दोनों ही Users के लिए उनका Data Disconnected Mode में Available हो गया। परिणामस्वरूप दोनों ही Users Underlying Database से पूरी तरह से Disconnected हैं, इसलिए Application में नया Record Add करते समय दोनों ही Users समान Primary Key के रूप में CustomerID Field में Data Insert कर सकते हैं।

क्योंकि दोनों ही Users के Frontend को ये बात बताने का कोई तरीका Exist नहीं है, कि किसी एक User ने समान Primary Key को किसी Record में पहले से ही Enter कर दिया है और दो अलग Users समान Primary Key Data इसलिए Insert कर सकते हैं, क्योंकि दोनों ही Users Disconnected Mode में अपने DataSet Object में नया Record Enter कर रहे हैं, जो कि Underlying Data Source से पूरी तरह से Disconnected है।

समस्या तब पैदा होती है, जब दोनों Users अपने Disconnected DataSet में Add किए गए नए Record को Underlying DataSource में Save करते हैं। इस स्थिति में जो User अपने Record को पहले Save करता है, उसे किसी तरह की कोई परेशानी नहीं होती, लेकिन जो User अपने Record को बाद में Save करता है, उस User को एक Exception Return होता है।

क्योंकि जब दूसरा User अपने Record को Underlying Database में Save करता है, तो उसने अपने Record में जो Primary Key Add किया है, वह Primary Key, Underlying Database में पहले User द्वारा Save किए गए Record के Save होने के कारण पहले से Exist है। यानी दूसरा User तब तक अपने Record को Save नहीं कर सकता, जब तक कि वह Primary Key के रूप में किसी दूसरी Value को Specify न करे।

लेकिन सवाल ये है कि दूसरे User को इस बात का पता कैसे चलेगा, कि वह जो Key Value Insert कर रहा है, वह Key Value पहले से Use नहीं हो चुकी है, क्योंकि इस बात का पता दूसरे User को तभी हो सकता है, जबकि Underlying Data Source में नया Record Save होते ही, इस दूसरे User के DataSet के Records भी Underlying Database में होने वाले Changes के अनुसार तुरन्त Refresh हों।

यानी Underlying Data Source में नया Record Add हो या Transaction Fail हो जाए, दोनों ही स्थितियों में दूसरे User के DataSet Object का Data Underlying Database के Latest Data से Refresh होना चाहिए, ताकि DataSet Object, Duplicate Primary Key Value को Insert होने से रोकने के लिए दूसरे User को Error Message दे सके।

इस प्रकार की Conflicts को Handle करने का काम ADO.NET स्वयं ही अपने स्तर पर करता रहता है। यानी हमें हमारे DataSet को बार-बार Underlying Database में होने वाले Changes को Reflect करने के लिए किसी प्रकार का Code लिखने की जरूरत नहीं होती।

क्योंकि जब हम उपरोक्तानुसार Drag-and-Drop तकनीक का प्रयोग करके अपना Application Form Create करते हैं, तब हालांकि हम एक भी Line का Code नहीं लिखते, लेकिन फिर भी Visual Studio स्वयं अपने स्तर पर बहुत सारी Coding Create करता है और ये Code ही Disconnected Mode में Add किए गए Records को न केवल Underlying Database में, बिना कोई Concurrency Issue Generate किए हुए Insert करता है, बल्कि Records को Delete व Update करने से सम्बंधित विभिन्न प्रकार के जरूरी Operations Perform करने की क्षमता भी Provide करता है।

इस Auto-Generated Codes की एक सबसे बडी विशेषता ये है कि हम कभी भी UPDATE, DELETE या INSERT SQL Command Use नहीं करते। बल्कि DataSet Create होने के बाद हम ज्यादा से ज्यादा SELECT SQL Statement को ही Specify या Modify करते हैं, जैसाकि इस Chapter की शुरूआत में Discuss किया गया था। जबकि इस SELECT Statement के आधार पर ही Visual Studio स्वयं ही INSERT, UPDATE व DELETE SQL Commands के लिए Automatically Codes Generate कर देता है। इन Auto-Generated Codes की Working को समझने के लिए हम हमारे Automatically Create होने वाली .xsd File की .Designer.cs File को देख सकते हैं।