व्याख्या:
ऐसा लगता है कि आप जो चाहते हैं वह किसी प्रकार की प्रणाली है जहां काम पर दो (या अधिक) धागे हो सकते हैं। एक थ्रेड डेटाबेस से डेटा को समकालिक रूप से लाने और बाकी प्रोग्राम को इसकी प्रगति की रिपोर्ट करने में व्यस्त होगा। दूसरा थ्रेड डिस्प्ले से संबंधित होगा।
यह स्पष्ट नहीं है कि आपकी क्वेरी 500,000 पंक्तियाँ लौटाएगी (वास्तव में, हमें आशा है कि ऐसा नहीं होगा), हालाँकि इसे सभी 500,000 पंक्तियों को स्कैन करना पड़ सकता है (और अच्छी तरह से केवल 23 पंक्तियाँ मिली हैं जो अब तक मेल खाती हैं)। लौटाई जाने वाली पंक्तियों की संख्या निर्धारित करना कठिन है; स्कैन की जाने वाली पंक्तियों की संख्या निर्धारित करना आसान है; पहले से स्कैन की गई पंक्तियों की संख्या निर्धारित करना बहुत कठिन है।
इसलिए, उपयोगकर्ता ने 23वीं पंक्ति से आगे स्क्रॉल किया है, लेकिन क्वेरी अभी तक पूरी नहीं हुई है।
यहां एक दो मुद्दे हैं। डीबीएमएस (अधिकांश डेटाबेसों का सच, और निश्चित रूप से आईडीएस का) एक बयान को संसाधित करने पर वर्तमान कनेक्शन तक जुड़ा हुआ है। कोई प्रश्न कैसे आगे बढ़ा, इस पर प्रतिक्रिया प्राप्त करना कठिन है। क्वेरी शुरू होने पर आप अनुमानित पंक्तियों को देख सकते हैं (SQLCA संरचना में जानकारी), लेकिन वे मान गलत होने के लिए उपयुक्त हैं। आपको यह तय करना होगा कि जब आप 23 की पंक्ति 200 पर पहुँचते हैं, या आप 5,697 की पंक्ति 23 पर पहुँचते हैं तो क्या करना है। यह कुछ नहीं से बेहतर है, लेकिन यह विश्वसनीय नहीं है। यह निर्धारित करना कि कोई प्रश्न कितना आगे बढ़ चुका है, बहुत कठिन है। और कुछ प्रश्नों के लिए एक वास्तविक सॉर्ट ऑपरेशन की आवश्यकता होती है, जिसका अर्थ है कि यह अनुमान लगाना बहुत कठिन है कि इसमें कितना समय लगेगा क्योंकि सॉर्ट किए जाने तक कोई डेटा उपलब्ध नहीं है (और एक बार सॉर्ट हो जाने के बाद, संवाद करने में केवल समय लगता है डेटा की डिलीवरी को रोकने के लिए DBMS और एप्लिकेशन)।
Informix 4GL में कई खूबियां हैं, लेकिन थ्रेड सपोर्ट उनमें से एक नहीं है। भाषा को थ्रेड सुरक्षा को ध्यान में रखकर नहीं बनाया गया था, और इसे उत्पाद में फिर से लगाने का कोई आसान तरीका नहीं है।
मुझे लगता है कि आप जो खोज रहे हैं वह दो धागे द्वारा आसानी से समर्थित होगा। I4GL प्रोग्राम जैसे एकल-थ्रेडेड प्रोग्राम में, उपयोगकर्ता द्वारा कुछ और इनपुट टाइप करने के लिए प्रतीक्षा करते हुए पंक्तियों को बंद करने और लाने का कोई आसान तरीका नहीं है (जैसे 'डेटा से भरे अगले पृष्ठ को नीचे स्क्रॉल करें')।
पहली पंक्ति का अनुकूलन डीबीएमएस के लिए एक संकेत है; यह कथित प्रदर्शन को महत्वपूर्ण लाभ दे सकता है या नहीं भी दे सकता है। कुल मिलाकर, इसका आम तौर पर मतलब है कि क्वेरी को डीबीएमएस परिप्रेक्ष्य से कम बेहतर तरीके से संसाधित किया जाता है, लेकिन उपयोगकर्ता को जल्दी से परिणाम प्राप्त करना डीबीएमएस पर कार्यभार से अधिक महत्वपूर्ण हो सकता है।
कहीं नीचे एक बहुत कम वोट वाले उत्तर में, फ्रैंक चिल्लाया (लेकिन कृपया चिल्लाओ मत):
ठीक है। यहां कठिनाई दो क्लाइंट-साइड प्रक्रियाओं के बीच आईपीसी का आयोजन कर रही है। यदि दोनों डीबीएमएस से जुड़े हैं, तो उनके अलग-अलग कनेक्शन हैं, और इसलिए एक सत्र के अस्थायी टेबल और कर्सर दूसरे के लिए उपलब्ध नहीं हैं।
सभी प्रश्नों का परिणाम एक अस्थायी तालिका में नहीं होता है, हालांकि स्क्रॉल कर्सर के लिए सेट किए गए परिणाम में आमतौर पर लगभग एक अस्थायी तालिका के बराबर होता है। आईडीएस को स्क्रॉल कर्सर का समर्थन करने वाली अस्थायी तालिका पर लॉक लगाने की आवश्यकता नहीं है क्योंकि केवल आईडीएस ही तालिका तक पहुंच सकता है। यदि यह एक नियमित अस्थायी तालिका होती, तब भी इसे लॉक करने की आवश्यकता नहीं होती क्योंकि इसे बनाने वाले सत्र के अलावा इसे एक्सेस नहीं किया जा सकता है।
शायद एक अधिक सटीक स्थिति संदेश होगा:
Searching 500,000 rows...found 23 matching rows so far
शायद; आप 'टेबल से COUNT(*) चुनें' के साथ एक तेज़ और सटीक गणना भी प्राप्त कर सकते हैं; यह कुछ भी स्कैन नहीं करता है, लेकिन केवल नियंत्रण डेटा तक पहुंचता है - संभवतः प्रभावी रूप से वही डेटा जो SMI तालिका sysmaster:sysactptnhdr के nrows कॉलम में होता है।
तो, एक नई प्रक्रिया को जन्म देना स्पष्ट रूप से सफलता का नुस्खा नहीं है; आपको क्वेरी परिणामों को उत्पन्न प्रक्रिया से मूल प्रक्रिया में स्थानांतरित करना होगा। जैसा कि मैंने कहा, अलग-अलग डिस्प्ले और डेटाबेस एक्सेस थ्रेड्स के साथ एक बहुप्रचारित समाधान फैशन के बाद काम करेगा, लेकिन I4GL का उपयोग करके ऐसा करने में समस्याएं हैं क्योंकि यह थ्रेड-जागरूक नहीं है। आपको अभी भी यह तय करना होगा कि क्लाइंट-साइड कोड प्रदर्शन के लिए जानकारी को कैसे संग्रहीत करेगा।
