2010-09-30 5 views
8

लेन-देन और डेटा-जागरूक घटकों का उपयोग करके डेल्फी डेटाबेस एप्लिकेशन लिखने का बेहतर तरीका क्या है?लेन-देन और डेटा-जागरूक घटकों के साथ डेल्फी डेटाबेस ऐप्स लिखने का पसंदीदा तरीका

मुझे एक क्लाइंट ऐप लिखना है जो इनो डीबी टेबल तक पहुंचता है, और लेन-देन के अंदर कुछ मास्टर-विवरण प्रकार की चीजें करता है। लेन-देन पर कुछ शोध करने के बाद (सामान्य बिंदु-दृश्य से), तो मैं विनम्रता से निष्कर्ष निकालता हूं कि गैर-डेटा-जागरूक घटक और हाथ-कोडित एसक्यूएल लेनदेन का "सही मिलान" होगा; लेकिन डेटा-जागरूक घटक नहीं होंगे। वे एक-दूसरे के लिए नहीं लगते हैं।

मेरे पास लेनदेन का उपयोग करने की वास्तविक आवश्यकता है, लेकिन दूसरी ओर मैं केवल डेटा-जागरूक घटकों को फेंक नहीं सकता क्योंकि वे चीजों को बहुत सरल बनाते हैं।

क्या कोई मुझे प्रबुद्ध कर सकता है? मैं इसे गुगल कर रहा हूं, लेकिन मुझे कोई उपयोगी जवाब नहीं मिला है। शायद क्योंकि मेरी अंग्रेजी पर्याप्त नहीं है कि मेरे कीवर्ड सीमित हैं।

बीटीडब्ल्यू, मैं डेल्फी 7 का उपयोग कर रहा हूं और वर्तमान में डेटा एक्सेस लाइब्रेरी के रूप में यूनीडीएसी का मूल्यांकन कर रहा हूं।

धन्यवाद।

संपादित

उदाहरण मेरे सवाल का एक पहलू का वर्णन करने के:

उस पर 2 DBGrids साथ एक रूप की कल्पना करें। पहला ग्रिड मास्टरग्रिड है और इसके ऊपर ये बटन हैं: जोड़ें, & हटाएं। दूसरा ग्रिड DetailGrid है। उपयोगकर्ता क्लिक करें, तो यह इस तरह जाना:

  • Connection.StartTransaction
  • Master.Append तो Master.Post तो Master.Edit (यह संपादन योग्य है तो मास्टर डाटासेट autoincrement प्राथमिक कुंजी है, और अब)
  • संपादन प्रारूप को सामान्य रूप से दिखाएं, जिसमें उपयोगकर्ता मास्टर रिकॉर्ड भरता है, और किसी अन्य रूप का उपयोग करके कुछ विवरण रिकॉर्ड भी जोड़ता है।
  • यदि उपयोगकर्ता ठीक क्लिक करता है, तो ऐप मास्टर करेगा। पोस्ट और कनेक्शन। कॉमिट। यदि उपयोगकर्ता रद्द करें पर क्लिक करता है, तो ऐप कनेक्शन करेगा। रोलबैक।

मुझे पता है कि लेनदेन जितना संभव हो उतना छोटा होना चाहिए, लेकिन आप ऊपर देख सकते हैं कि लेनदेन केवल उपयोगकर्ता भरने की गति जितनी छोटी है।

यदि मैं गैर डेटा-जागरूक घटकों का उपयोग कर रहा था, तो मैं उपयोगकर्ता इनपुट के आधार पर कस्टम सम्मिलित एसक्यूएल बनाउंगा, फिर स्टार्टट्रांसक्शन और कमिट के बीच एसक्यूएल निष्पादित करूंगा। तो मैं बहुत छोटा लेनदेन प्राप्त कर सकता हूं।

संपादित 2

मैं अपनी तरह की भागीदारी के लिए आप सभी को धन्यवाद देता हूं। मैं vcldeveloper से जवाब चुनता हूं क्योंकि यह मेरी वर्तमान आवश्यकता का सबसे निकटतम समाधान है।

+0

हाय, कोकीन। StackOverflow में आपका स्वागत है। आपका प्रश्न विशेष रूप से स्पष्ट नहीं है। डेटा जागरूक नियंत्रण और लेन-देन एक-दूसरे के साथ काम करने के साथ आपको क्या समस्याएं आ रही हैं? क्या आप अधिक जानकारी प्रदान करने के लिए अपना प्रश्न संपादित कर सकते हैं? –

+0

आप क्यों कहते हैं कि डेटा-जागरूक घटक लेनदेन के लिए अच्छे नहीं हैं? लेनदेन आमतौर पर डेटाबेस सत्र स्तर पर संभाला जाता है - यदि डीएमएल आदेश हाथ से बना एसक्यूएल से आते हैं या इससे कोई फर्क नहीं पड़ता है। –

उत्तर

3

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

के लिए एडीओ, आप क्या करना चाहिए ltBatchOptimistic करने के लिए अपने डेटासेट के LockType स्थापित करने के लिए है। यूनीडीएसी के लिए, आपको कैशअपडेट संपत्ति पर सही सेट करना चाहिए।

यह परिवर्तन सभी परिवर्तनों को आप उसके इन-स्मृति recordset पर बनाने के कैश, और उन्हें alltogether भेज डेटाबेस के लिए केवल जब आप कॉल UpdateBatch विधि (एडीओ) या ApplyUpdates विधि (UniDAC) करने के लिए अपने डाटासेट बनाता है।

अब आपको क्या करना चाहिए, अपने उपयोगकर्ता को मास्टर डेटासेट में रिकॉर्ड डालने/संपादित करने और आपके इच्छित डेटा-जागरूक घटकों का उपयोग करके विवरण डेटासेट में जो भी रिकॉर्ड चाहिए, उसे देना है। सभी बदलाव कैश किए जाएंगे। जब आपका उपयोगकर्ता किया जाता है, तो आप एक नया लेनदेन शुरू कर सकते हैं, और मास्टर डेटासेट के लिए पहले अपडेटबैच (या यूनीडीएसी के मामले में आवेदन अपडेट) को कॉल कर सकते हैं, और उसके बाद विवरण डेटासेट के लिए, और यदि सब कुछ ठीक हो जाता है, तो लेनदेन करें।

इससे क्लाइंटडेटसेट की अतिरिक्त परत की आवश्यकता के बिना आपके लेन-देन कम हो जाएंगे।

सम्मान

5

मैं आपके प्रश्न को समझता हूं, मुझे लगता है। उदाहरण के साथ एक TADODataSet खोलते समय डेटा-जागरूक घटकों के साथ डेटा के 10 पंक्तियों को संपादित करने के लिए, ऐसी स्थितियां हैं जिनमें आप सभी 10 पंक्तियों (और संभवतः हटाने और सम्मिलन) में किए गए सभी परिवर्तनों को कैश करना चाहते हैं और इसे एक बैच के रूप में प्रतिबद्ध करना चाहते हैं । आप पहले बदलाव पर लेनदेन नहीं खोल सकते हैं, जिसके लिए अन्य उपयोगकर्ताओं को एक ही डेटा को बदलना होगा। लेनदेन जितना संभव हो उतना छोटा होना चाहिए।

TADOConnection >> TADODataSet >> TDataSetProvider >> TClientDataSet >> TDataSource >> TDBEdits आदि

अब सभी परिवर्तनों को कैश नहीं किया जाता:

मैं sketched परिदृश्य में क्या करना एक श्रृंखला में निम्नलिखित घटकों का उपयोग है TClientDataSet में और आप एक तेज़ लेन-देन में सभी परिवर्तनों को पोस्ट करने के लिए आवेदन विधि को अपडेट कर सकते हैं। ध्यान दें कि नेस्टेड डेटासेट के साथ मास्टर-विवरण (-detail-etc) संरचना के लिए एकाधिक TADODataSets और एकाधिक TClientDataSets का उपयोग करना भी संभव है। सभी मास्टर-विस्तार परिवर्तनों को भी एक लेनदेन में एक बैच में कैश किया जा सकता है और लागू किया जा सकता है। इसे लागू करने के बारे में सभी विवरणों के लिए कहीं और सहायता और संसाधन देखें। पहले यह आसान नहीं है। लेकिन अगर आपने इसे समझ लिया तो यह आसान है और कई संभावनाएं प्रदान करता है। (ऑफ़लाइन संपादन, उन्हें लागू करने से पहले परिवर्तन की जांच आदि)

+0

हां, आपका विवरण सही है। धन्यवाद। यद्यपि यह कुछ हद तक जटिल लगता है, मैं उस घटक श्रृंखला के बारे में जानेंगे जिसे आपने संभावित समाधान में से एक के रूप में वर्णित किया है। – Cocin

0

लेनदेन जितना छोटा होना चाहिए। समस्या यह है कि विभिन्न डेटाबेस लॉकिंग कैसे संभालते हैं। डेटाबेस जो केवल पंक्ति-स्तर लॉकिंग करते हैं और बिना प्रतीक्षा किए लॉक से तुरंत लौट सकते हैं, डेडलॉक के लिए बहुत कम संभावना है। आम तौर पर आवेषण कम समस्याग्रस्त होते हैं (हालांकि अलगाव स्तर के आधार पर अन्य उपयोगकर्ता प्रतिबद्ध होने तक नई पंक्तियां नहीं देख पाएंगे), अपडेट और डिलीट अधिक समस्याग्रस्त हैं। अक्सर काम करना भी "बुरा" हो सकता है। कैशिंग परिवर्तन और उन्हें एक ही परिचालन में लागू करना एक और संभावना है - लेकिन आपको अन्य उपयोगकर्ताओं को रिकॉर्ड बदलने के कारण मुद्दों को संभालना होगा। कोई "बेहतर" समाधान नहीं है - सब कुछ वास्तविक आवश्यकताओं पर निर्भर करता है। कुछ अनुप्रयोगों (और कुछ डेटाबेस) के लिए जब तक वे बदल रहे हैं तब तक लॉक रिकॉर्ड को ठीक रखना, ठीक है, दूसरों के लिए नहीं हो सकता है। कुछ परिदृश्यों में बैच अपडेट ठीक हो सकते हैं, न कि दूसरों में। आपको उस मॉडल का चयन करना होगा जो आपके एप्लिकेशन और डेटाबेस के लिए सबसे अच्छा काम करता है।

2

बड़े लेनदेन प्रदर्शन करने की जरूरत से बचने के लिए मैं DataSetProviders और ClientDatasets (यहां तक ​​कि स्थानीय स्तर पर) का उपयोग करें।

कैश का एक प्रकार के रूप में इसके उपयोग पर विचार और यह आप दोनों दुनिया के सर्वश्रेष्ठ देता है। आप जबकि यूआई पर काम कर बातें सरल करने के लिए डेटा अवगत नियंत्रण का उपयोग कर सकते हैं। डेटासेट से अधिक उपयोगकर्ता क्रियाएं ClientDataSets (डेटाबेस कैश की तरह) द्वारा "रिकॉर्ड" कर रहे हैं।

अपने उपयोगकर्ता बचाने डेटाबेस में परिवर्तन के लिए तैयार हैं जब (उदाहरण के लिए, चालान डेटा सभी जगह में है), तो आप डाटासेट (रों) के लिए ApplyUpdates विधि कॉल।

सबसे सरल परिदृश्य में, जहां सभी डेटासेट मास्टर-विस्तार संबंध (प्रदाता द्वारा घोंसला) में हैं, प्रदाता शुरू होता है और लेन-देन को खुद ही लेन-देन करता है, इसलिए आप स्वचालित रूप से सभी या कुछ भी स्थिति में नहीं हैं।

यदि आपके पास अधिक जटिल संबंध हैं, तो आप प्रत्येक शामिल क्लाइंटडेटा सेट सेट के लिए अपडेट लागू करने से पहले स्टार्टट्रांसेंस को कॉल कर सकते हैं, और अंत में कॉमिट या रोलबैक को आवश्यकतानुसार कॉल करें)। प्रदाता के लिए तर्क है, तो कनेक्शन एक सक्रिय लेनदेन जब ApplyUpdates कहा जाता है, तो यह लेनदेन के साथ कुछ नहीं करता है, लेकिन बस डेटाबेस में परिवर्तन पोस्ट, यह मानते हुए आप लेनदेन के नियंत्रण में हैं है।

आपको टी क्लाइंटडेटासेट के बारे में पढ़ना है और ऑनरकोन्सीलर को कैसे संभालना है और इसे उत्पादन वातावरण में डालने से पहले तकनीक के साथ प्रयोग करना है, लेकिन यह मेरे लिए बहुत अच्छा काम करता है।

मेरा 2 सेंट।

1

आप बिल्कुल सही हैं कि लिखें लेनदेन जितना संभव हो उतना छोटा होना चाहिए, और यह उपयोगकर्ता हर समय जीवित नहीं होना चाहिए, जबकि उपयोगकर्ता फॉर्म भर रहा है।

सामान्य समाधान, जैसा कि पहले से ही उत्तर दिया गया है, एक मध्यवर्ती स्तर (क्लाइंटडेटासेट) का उपयोग करना है। लेकिन आपके परिदृश्य के साथ वास्तविक समस्या यह है कि आप बिना मास्टर के मास्टर मास्टर के लिए एक ऑटोइनक्रिकमेंट वैल्यू प्राप्त नहीं कर सकते हैं। ऐपेंड और मास्टर.पोस्ट, और इसके परिणामस्वरूप आप लिखने के लिए वास्तव में आवश्यक होने से पहले लिखते हैं।

तो तुम मध्यवर्ती स्तर का उपयोग करें और अभी भी लेनदेन आप एक डेटाबेस (मास्टर मेज पर) सम्मिलित करें क्रियान्वित करने के बिना एक autoincremented मूल्य प्राप्त करने का समर्थन करता है के बारे में सोच चाहिए कम लिखने के साथ डेटा अवगत घटकों का उपयोग नहीं करना चाहते हैं। उदाहरण फ़ायरबर्ड डेटाबेस है, और फ़ायरबर्ड के लिए FibPlus डेटा एक्सेस घटक पूरी तरह से इस सुविधा का समर्थन करते हैं।

+0

कुछ डेटाबेस उपयोगकर्ता को बहुत कम लेनदेन का उपयोग करने के लिए मजबूर करते हैं, क्योंकि वे समेकन को अच्छी तरह से संभाल नहीं सकते हैं। लेकिन डेटा अखंडता और स्थिरता की रक्षा के लिए लेनदेन हैं। जैसा कि टॉम क्यटे (asktom.oracle.com) ने लिखा था: "लेनदेन जितना बड़ा होना चाहिए उतना बड़ा होना चाहिए [...] लेनदेन बिल्कुल तब तक होना चाहिए जब तक उन्हें होना चाहिए (लेकिन अब नहीं)। कंप्यूटर या उसके सॉफ्टवेयर की सुविधा के लिए लेनदेन नहीं है। वे आपके डेटा की रक्षा कर रहे हैं "। –

संबंधित मुद्दे