Disconnected Data History Handling

हम उपरोक्तानुसार Discussed विभिन्न तरीकों में से किसी भी तरीके का प्रयोग करके Disconnected Data को Add, Modify या Delete करें, Underlying Database पर उसका तब तक कोई प्रभाव नहीं पडता, जब तक कि हम DataAdapter Object के Update() Method को Use नहीं करते। इसलिए जब तक हम DataAdapter के माध्‍यम से Underlying DataSource पर Modified Data को Permanently Update नहीं करते, तब तक हम हमारे DataRow की History को Check कर सकते हैं और ये काम कुछ निम्नानुसार किया जा सकता है:

	DataRow dr;
	dr = empTable.Rows[0];
	dr.BeginEdit();
	dr["FirstName"] = "Rajesh";
	Console.Write(dr["FirstName", DataRowVersion.Proposed]);
	dr.EndEdit() ;
	Console.Write(dr["FirstName", DataRowVersion.Original]);
	Console.Write(dr["FirstName", DataRowVersion.Current]);

चूंकि हम DataRowVersion को किसी भी Column Name के साथ Use कर सकते हैं। इसलिए Current, Original, Proposed या Default में से किसी भी Version को DataRow के साथ Specify करके DataRow Object के विभिन्न Versions को Retrieve कर सकते हैं। यानी-

Current Constant

जब हम इस Constant को Use करते हैं, तो हमें हमारे Row के Column में Stored Data का Current मान प्राप्त होता है।

Original Constant

जब हम इस Constant को Use करते हैं, तो हमें हमारे Row के Column में Stored Data का Original मान प्राप्त होता है। यानी यदि Column के मान को Change भी कर दिया गया हो, तो Change किए जाने से पहले उस Column में जो मान था, वह मान हमें इस Constant को Specify करने पर प्राप्त होता है।

Proposed Constant

जब हम इस Constant को Use करते हैं, तो हमें हमारे Row के Column में Store होने वाली Proposed Value प्राप्त होता है, जो कि BeginEdit() व Update() के बाद जबकि EndEdit() से पहले Fetch होता है। यानी Column के मान को Change करने के बाद क्या मान Stored होगा, वह मान हमें इस Constant को Specify करने पर प्राप्त होता है।

Default Constant

जब हम इस Constant को Use करते हैं, तो हमें हमारे Row के Column से वह Value प्राप्त होता है, जो तब प्राप्त होता है, जबकि हम उस Column के साथ किसी Constant को Use नहीं करते।

ADO.NET हमें DataSet नाम का Records का एक Disconnected Cache Retrieve करने की सुविधा देता है, जो कि In-Memory Database की तरह व्‍यवहार करता है। ये हमें हमारे DataSet Object में Stored Data को न केवल Disconnected Mode में Search, Sort व Filter करने की सुविधा देता है, बल्कि हम इस DataSet Object में Stored DataTables के बीच ठीक उसी तरह से Relationship को भी Maintain कर सकते हैं, जिस तरह से Real Database की Tables के बीच Relationship होती है। साथ ही हम Underlying Database के Tables के Data को XML Representation में भी Update कर सकते हैं और Object Representation में भी।

लेकिन DataSet Object पूरी तरह से Database नहीं होता और इसे Database की तरह Treat भी नहीं करना चाहिए। Connected Environment में हम बडी ही आसानी से विभिन्न Relational Data को Insert, Update व Delete कर सकते हैं। लेकिन जब हम Disconnected Data के साथ प्रक्रिया कर रहे होते हैं, तब हमें Latest Generated Keys व Concurrency को भी Manage करने की जरूरत पडती है।

जबकि एक से ज्यादा Tables जब आपस में Related होते हैं साथ ही Disconnected Mode में होते हैं, तब DataTables के बीच बनने वाली Hierarchy के आधार पर किसी Requirement को पूरा करने के लिए हमें Complex SQL Queries के आधार पर Resultset Generate करने की भी जरूरत पडती है।

चूंकि DataSet पूरी तरह से Disconnected होता है, इसलिए जब हम हमारे Frontend Application के माध्‍यम से DataSet Object के Data में किसी प्रकार का Change करते हैं, तो उसका प्रभाव तब तक Underlying Database पर नहीं पडता, जब तक कि हम DataAdapter Object के Update() Method को Use न करें।

सामान्यत: DataAdapter एक Single Table या Row Arrays को ही Update कर सकता है। इसलिए यदि हमें Multiple Tables की Relationship के आधार पर Generate की जाने वाली Complex SQL Queries के आधार पर Underlying Database की एक से ज्यादा Related Tables के Data को Update करना हो, तो हम केवल DataAdapter Object के Update() Method का प्रयोग करके इस जरूरत को पूरा नहीं कर सकते। बल्कि इस स्थिति में हमें हमारा स्वयं का SQL Command लिखना जरूरी होता है।

Disconnected DataSet में हम चाहे जो भी Change करें, वह Change तब तक Underlying Database में Reflect नहीं होता, जब तक कि हम DataAdapter के Update() Method को Use न करें। जबकि यदि समान Application को एक से ज्यादा Users Concurrently Use कर रहे हों, तो सभी का अपना अलग Disconnected DataSet Object होगा।

परिणामस्वरूप सभी Users अपने स्वयं के DataSet Object में जो चाहें वो Change करें, उनके द्वारा किए गए Changes तब तक किसी भी अन्य User को Reflect नहीं होंगे, जब तक कि वे Users अपने DataSet Object के Data को Underlying Database में Save करने के लिए Update() Method का प्रयोग न करें।

Underlying Database की Query करने व Underlying Database में DataSet Object के Data को Save करने के दौरान कई प्रक्रियाऐं होती हैं, जिन्हें ध्‍यान में रखे बिना हम एक अच्छा Application Create नहीं कर सकते। उदाहरण के लिए जब हम Multi-User Mode में किसी Application को Develop करते हैं, तो-

• जिस Row को हम हमारे DataSet Object में Update करना चाहते हैं, उसे किसी अन्य User द्वारा Update या Delete किया जा चुका हो सकता है।
• जिस Row को हम Insert कर रहे हैं, उसकी किसी अन्य Table की Row के साथ Foreign-Key Relationship हो सकती है, जिसे किसी अन्य User द्वारा उसी समय के दौरान Delete किया जा चुका हो सकता है।
• जिस Row को हम Update करना चाहते हैं, उसे किसी अन्य User द्वारा पहले ही Update किया जा चुका हो सकता है, जबकि उस दूसरे User ने हो सकता है कि उसी Column को Update न किया हो, जिसे Update करना हमारी जरूरत है। इस स्थिति में इस बात का निर्ण; लेना कि हमारे द्वारा किया गया Update Accept हो या Reject, काफी असुविधाजनक हो जाता है।
• हम Hierarchical Form में Row Insert करने की कोशिश कर सकते हैं। जिसमें Insert होने वाली एक Row में हमें Foreign Key Value को Insert करना है, जिसके Association में हम किसी Row को Insert या Update करना चाहते हैं, जबकि वह Row हमारे DataSet Object का Part हो भी सकता है और नहीं भी।

यानी Multi-User Mode में ऐसी बहुत सारी समस्याऐं हो सकती हैं, जिन्हें ध्‍यान में रखे बिना हम Perfect Multi-User .NET Database Application Create नहीं कर सकते हैं। इसलिए जब हम Multi-User Application Design कर रहे होते हैं, तो हमें इन विभिन्न प्रकार के Scenarios को ध्‍यान में रखते हुए ही अपना Update Logic Design करना होता है। ताकि किसी भी प्रकार के Conflict का पता लगाया जा सके व Concurrency को आसानी से Handle किया जा सके।

हमें हमारा Database व Frontend Application इस तरह से Design करना होता है कि किसी भी तरह का Conflict पैदा न हो। सामान्यत: Disconnected Mode में सबसे पहले पैदा होने वाला Conflict Primary Key से सम्बंधित होता है। क्योंकि एक से ज्यादा Users समान Database के Data Snapshoot को अपने DataSet Object में Retrieve करते हैं। इसलिए जब अलग-अलग Users अपने Disconnected DataSet Object में नया Record Add करके Underlying Database में Update करते हैं, तो अलग-अलग Users द्वारा समान Primary Key के Rows को Database में Update करने की वजह से Conflict पैदा होता है।

क्योंकि किसी भी दूसरे User को तब तक इस बात का पता नहीं चलता कि किसी अन्य User ने उस Primary Key के लिए Underlying Database में कोई Row Insert कर दिया है, जब तक कि दूसरा User अपना Record Underlying Database में Save करने के लिए Update() Method का प्रयोग नहीं करता।

इस स्थिति में हम अपनी जरूरत व सुविधा के आधार पर अपने Primary Key के Logic को Implement करते हैं ताकि एक से अधिक Users समान Underlying Database पर काम करने के बावजूद उनके द्वारा Update किए जाने वाले Disconnected Data के कारण Primary Key Related Conflict पैदा न हो।