2016-01-24 3 views
5

मैं डेटाबेस को बदलने के बाद उपयोग करने के लिए इच्छित आदेशों को समझने के लिए संघर्ष कर रहा हूं। मैं SQLite3 और डीबी-जागरूक नियंत्रणों के माध्यम से सीख रहा हूं, और यहां मेरी समझ है ...डेटाबेस, पोस्ट के लिए पोस्ट, ApplyUpdates, और Commit के बीच क्या अंतर है?

जब कोई उपयोगकर्ता डीबी-जागरूक नियंत्रण में कुछ टाइप करता है (या अन्यथा स्मृति स्थिति में मेमोरी डेटासेट में डालता है), POST स्टोर करेगा स्मृति में परिवर्तन। नियंत्रण अक्सर आपके लिए स्वचालित रूप से, या निस्संदेह, यह आपके लिए करते हैं।

हालांकि किसी भी बदलाव को कहीं भी पहचानने से पहले आपको पोस्ट करना होगा, परिवर्तन डिस्क पर वास्तविक डेटाबेस फ़ाइल में नहीं भेजे गए हैं। वे केवल स्मृति में हैं। डिस्क में परिवर्तन भेजने के लिए APPLYUPDATES की आवश्यकता है।

APPLYUDATES के माध्यम से डिस्क पर फ़ाइल में भेजने के बाद भी वे अभी भी बदल सकते हैं, या वापस लुढ़क सकते हैं। यह पूर्ववत मारने जैसा है। COMMIT तक उन्हें डिस्क पर स्थायी रूप से सहेजा नहीं जाता है।

क्या यह सही है? मैं वास्तव में जानना चाहता हूं कि मैं क्या कर रहा हूं इसलिए मैं सिर्फ कोड कॉपी और पेस्ट नहीं कर रहा हूं। लेकिन कृपया अपने उत्तर में मेरे प्रयास को कॉपी, पेस्ट और संपादित करने के लिए स्वतंत्र महसूस करें।

+0

आपको अपने डेल्फी कोड में कमिट कॉल करने की आवश्यकता नहीं हो सकती है। सर्वर कनेक्शन (डिफ़ॉल्ट रूप से कॉन्फ़िगर किया जा सकता है) सर्वर पर सबमिट किए गए परिवर्तनों को एक निहित लेनदेन में लपेट सकता है। SQLite के लिए, जिसमें कोई सच्चा सर्वर नहीं है, केवल एक डीएलएल है, यह आपके द्वारा उपयोग किए जा रहे TDataSet-वंशज घटक पर निर्भर हो सकता है - उनके दस्तावेज़ या स्रोत-कोड की जांच करता है। – MartynA

उत्तर

10

आपके प्रश्न का उत्तर यह है कि पोस्ट, ApplyUpdates और Commit पूरी तरह से अलग-अलग चीजें करते हैं और आम तौर पर डेटाबेस ऐप में विभिन्न स्थानों (प्रक्रियाओं) और संदर्भों में होते हैं।

Post और ApplyUpdates, दोनों वास्तव में क्लाइंट साइड संचालन कर रहे हैं, जबकि Commit किसी SQL आपरेशन हो सकता है (या नहीं) स्पष्ट रूप से एक सौदे को पूरा करने सर्वर साइड पर कहा जा करने की जरूरत है कि है।

यदि आप तीन-स्तरीय सर्वर पर विचार करते हैं तो मतभेदों को समझना सबसे आसान है। SQLite एक अजीब गेंद का एक छोटा सा है, क्योंकि यह एक प्रकार का सच्चा एसक्यूएल सर्वर नहीं है जिसे विभिन्न मशीनों पर विभिन्न प्रक्रियाओं से कॉल का जवाब देने के लिए डिज़ाइन किया गया है (हालांकि यह 3-स्तरीय सिस्टम_ के बैक-एंड के रूप में ऐसा कर सकता है।

सबसे सरल पारंपरिक 3-स्तरीय व्यवस्था के बारे में एक मध्य-स्तरीय डेल्फी सर्वर है जो एसक्यूएल सर्वर के बीच बैठता है, एक एमएस एसक्यूएल सर्वर और क्लाइंट-स्तरीय कहते हैं, आमतौर पर क्लाइंट मशीन पर चल रहे आपके डेल्फी प्रोग्राम। बोर्लैंड/ईएमबीए का पारंपरिक प्रौद्योगिकी को लागू करने के लिए इस DataSnap है।

ग्राहक स्तरीय आम तौर पर एक TClientDataSet (या 3 पार्टी समकक्ष) है कि मध्यम स्तरीय में एक सर्वर विशेष TDataSet वंशज के माध्यम से एक बैक-एंड SQL सर्वर से डेटा प्राप्त होता है। हालांकि हो रही डेटा एफ मध्यम स्तर पर एसक्यूएल सर्वर को रोम आमतौर पर एसक्यूएल सर्वर पर एक लेनदेन शामिल करता है, एक बार डेटा क्लाइंट स्तरीय में सीडीएस में लोड होने के बाद, SQL सर्वर पर कोई लेनदेन लंबित नहीं होता है (जब तक कि आप अपने रास्ते से बाहर नहीं जाते सर्वर पर एक लेनदेन खुला है, जो सर्वर के अन्य उपयोगकर्ताओं के अनुकूल नहीं है और सर्वर पर लॉक संसाधनों का उपभोग करता है, जो सीमित हैं)।

जब आप सीडीएस (या किसी भी टीडीसेटसेट वंशज, वास्तव में) में डेटा संपादित करते हैं, जो डेटासेट को डीएसएडिट स्थिति में डालता है (TDataSetState के लिए ऑनलाइन सहायता देखें)। किए गए परिवर्तन अस्थायी हैं, जिसका अर्थ है कि जब तक आप कॉल नहीं करते हैं, उन्हें सीडीएस में पूर्ववत किया जा सकता है। पोस्ट, जो उन्हें सीडीएस के डेटा में सहेजता है (TClientDataSet के मामले में, क्लाइंट-साइड डेटा में परिवर्तन को कॉल करने के बाद वापस ले जाया जा सकता है। पोस्ट, जब तक। लागू अद्यतनों को नहीं कहा गया है)। याद रखें कि एसक्यूएल सर्वर पर लंबित कोई लेनदेन नहीं है (या कम से कम, वहां नहीं होना चाहिए)। क्लाइंट स्तरीय में सीडीएस पर पोस्ट कहा जाता है।

कॉलिंग। नहीं है क्योंकि परिवर्तनों को समकक्ष मध्य-स्तरीय डेटासेट पर वापस प्रसारित किया जा सकता है। इसे आरंभ करने के लिए, आप क्लाइंट-स्तरीय सीडीएस पर ApplyUpdates को कॉल करते हैं, जो मध्य स्तर में TDataSetProvider के माध्यम से तरंगों को घुमाता है जो सीडीएस को मध्य-स्तर के सर्वर-फेससेट डेटासेट के साथ इंटरफेस करता है। यह DataSetProvider (या, अधिक सटीक रूप से एक TSqlResolver से जुड़ा हुआ है) जो एसक्यूएल उत्पन्न करता है जो वास्तव में SQL सर्वर में परिवर्तन लागू करने के लिए SQL सर्वर को भेजा जाता है। तो, मानक डेटा स्नैप 3-स्तरीय सेट-अप में, आपके पास कमिट को बुलाया गया है या नहीं, इस पर कोई प्रत्यक्ष नियंत्रण नहीं है।

Commit एसक्यूएल सर्वर द्वारा एक एसक्यूएल ऑपरेशन किया जाता है जो लेनदेन को पूरा करने के दो संभावित तरीकों में से एक है (दूसरा Rollback है)। एमएस एसक्यूएल सर्वर के साथ, f.i., सर्वर से कनेक्शन को UPDATE, INSERT और DELETE अंतर्निहित लेनदेन में बयानों को स्वचालित रूप से लपेटने के लिए कॉन्फ़िगर किया जा सकता है।

जिस सीमा तक आपको लेनदेन नियंत्रण के साथ खुद को चिंता करने की आवश्यकता है, वह बैक-एंड सर्वर पर निर्भर करता है और सर्वर डेटा के अन्य उपयोग के साथ सहमति के संदर्भ में आपके ऐप की आवश्यकताओं पर निर्भर करता है। यदि आप स्लाईट के लेनदेन के संचालन में रूचि रखते हैं, तो आप जिन डीकंपोनेंट्स का उपयोग कर रहे हैं या उनके स्रोत की सहायता के लिए दस्तावेज़ों से परामर्श लें।

वास्तविक SQL सर्वर के साथ काम करने के लिए कुछ डेल्फी घटक पुस्तकालय सर्वर-साइड लेनदेन को नियंत्रित करने के लिए सुविधाओं का खुलासा करते हैं, उदाहरण के लिए इंटरबेस के लिए आईबीएक्स।

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

+1

आपकी सूचनात्मक प्रतिक्रिया के लिए धन्यवाद। यह काफी उपयोगी है। ... बस अनुवर्ती करने के लिए, यदि किसी सर्वर को एक 'COMMIT' कमांड भेजना है, तो यह' ApplyUpdates' से पहले या उसके बाद होगा, क्या आपको लगता है? ऐसा लगता है कि कॉल से पहले मुख्य सर्वर पर अपडेट भेजने के लिए कोड किया जाएगा। –

+0

यदि आपका मतलब बैक-एंड सर्वर पर विशेष रूप से एक SQL COMMIT कथन है, तो यह आवश्यक है ** ** आवेदन के बाद ** होना आवश्यक है, क्योंकि यह तब तक नहीं है जब तक ApplyUpdates निष्पादित नहीं किया जाता है कि आवश्यक SQL अद्यतन आदेश बैक-एंड सर्वर पर भेजे जाते हैं लेन-देन COMMIT-ed में होने वाले परिवर्तनों को करने के लिए। – MartynA

-1

जब आप ApplyUpdates का उपयोग कर रहे हैं तो आपको CachedUpdates संपत्ति को सत्य पर सेट करना होगा। फिर आप पोस्ट का उपयोग कर सकते हैं, अपना डेटा बदलने के लिए हटाएं (और बाकी), इन परिवर्तनों को पहले कैश में रखा जाएगा। ApplyUpdates को कॉल करते समय आपके द्वारा किए गए सभी परिवर्तन डेटाबेस में संग्रहीत किए जाते हैं। CancelUpdates के साथ आप अपने द्वारा किए गए सभी परिवर्तनों को पूर्ववत कर सकते हैं। जब आप CachedUpdates प्रॉपर्टी को गलत पर सेट करते हैं तो आपके द्वारा सभी परिवर्तन सीधे डेटाबेस में संग्रहीत किए जाएंगे। आदेश लागू करें अद्यतन और रद्द करें अद्यतन का उपयोग नहीं किया जा सकता है।

+1

तो, फिर, 'COMMIT' क्या करता है? –

+0

अपने वर्तमान लेनदेन को समाप्त करने के लिए COMMIT कथन का उपयोग करें और लेनदेन में किए गए सभी परिवर्तनों को स्थायी बनाएं। परिवर्तनों को सहेजने के लिए। –

+1

मुझे जवाब देने के लिए समय निकालने के लिए धन्यवाद, इरेसा, –

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