एमएस एसक्यूएल सर्वर पर ओडीबीसी क्वेरी केवल 25 पीडीओ (फ्रीटीडीएस)

Question

में पहले 255 अक्षरों को लौट रही है, मैं वर्तमान में SQL सर्वर डेटाबेस दृश्य से कुछ डेटा खींचने की कोशिश कर रहा हूं कि हमने हमारे लिनक्स वेब सर्वर से पहुंच प्रतिबंधित कर दी है।

हमें डेटा को संपादित करने की आवश्यकता नहीं है बस इसे किसी वेबपृष्ठ में प्रदर्शित करें।

यह तब तक ठीक दिखता है जब तक कि हम आउटपुट करने का प्रयास न करें और केवल टेक्स्ट फ़ील्ड के पहले 255 वर्ण प्राप्त करें।

क्या किसी को पता है कि यह PHP :: पीडीओ के माध्यम से फ्रीटीडीएस का उपयोग करने में कोई समस्या है या यदि इसे ठीक काम करना चाहिए? मैंने अन्य लोगों को इसी तरह की समस्याएं देखी हैं, लेकिन कई जवाब नहीं लगते हैं।

मैं एमएस एसक्यूएल डाटाबेस के लिए कनेक्शन स्ट्रिंग के रूप में इस का उपयोग कर रहा:

$dbConn = new PDO("odbc:Driver=FreeTDS;DSN=OURDSN;UID=WWWUser;PWD=ourpassword"); 

Answer 1

FreeTDS User Guide के अनुसार, मुद्दा यह है कि FreeTDS केवल "प्रोटोकॉल परिभाषा में निहित सीमाओं की वजह से" जब एसक्यूएल सर्वर से बात कर varchar ऊपर से 255 पात्रों संभाल कर सकते हैं लगता है। उस से बड़ा कुछ भी डेटा प्रकार text होना चाहिए।

आप या तो इस तरह उसके अनुसार अपनी स्कीमा को संशोधित करने, या आपकी क्वेरी के दौरान डेटा प्रकार परिवर्तित करने, इस समस्या का समाधान कर सकते हैं:

SELECT CAST(mycol as TEXT) FROM mytable 

Answer 2

आप /etc/odbc.ini FreeTDS द्वारा इस्तेमाल किया फ़ाइल में पाठ क्षेत्रों के आकार को बढ़ा सकते हैं।

[name_of_connection] 
TextSize = 2097152 

तुम भी यकीन है कि तुम, डेटा पुनर्प्राप्ति के उस स्तर प्राप्त कर सकते हैं तो पीडीओ का उपयोग कर अप करने के लिए वापस काम करने के लिए पीएचपी निम्न स्तर ODBC दिनचर्या का उपयोग कर प्रयास कर सकते हैं।

Answer 3

FreeTDS डिफ़ॉल्ट रूप से, प्रोटोकॉल संस्करण 4.2 का उपयोग करता है आप को प्रोटोकॉल के हैं 7.0 आप वर्चर के 255 से अधिक बाइट पुनर्प्राप्त कर सकते हैं। आप "CAST" हैक का उपयोग कर सकते हैं, या आप कॉलम कॉल वर्कर (अधिकतम) को भी बदल सकते हैं।

वर्कर (अधिकतम) वर्चर (DATA_TYPE 2005 बनाम 12) की तुलना में एक पूरी तरह से अलग कॉलम प्रकार है और इसे freetds 4.2 w/o truncating पर स्ट्रीम किया जाएगा।

संस्करण 7 में अपग्रेड क्यों नहीं करें? चूंकि यूटीएफ -8 को नए प्रोटोकॉल के साथ वर्चर में संग्रहीत नहीं किया जा सकता है। SQL सर्वर UCS-2 (जैसे UTF-16) में सभी प्रोटोकॉल जानकारी प्रेषित करेगा और सहेजने से पहले आपके डेटा को तालिका या कॉलम संयोजन में परिवर्तित करेगा। लेकिन, इसके लिए आपको यूटीएफ 8 डेटा को एन.एनएसईआरटी के साथ टीबीएल (टीटीटी) मानों (एन'हेलो वर्ल्ड ') में

CAST क्यों नहीं है? CAST AS टेक्स्ट MySQL के साथ संगत नहीं है (CAST के रूप में CAST करने की आवश्यकता है)।

प्रोटोकॉल 4.2 पर रहना और अपने वर्चर्स को वर्चर (अधिकतम) के रूप में परिभाषित करना है, तो आप सबसे संगत एसक्यूएल लिखते हैं।

Answer 4

इस मुद्दे के लिए एक और तथ्य। 2015 तक, पहले 25 अक्षरों को स्पष्ट रूप से वापस लौटाए जाने वाले एक्सएमएल परिणामों के मूल्य को वापस लौटाते हुए। हालांकि, अधिकांश एक्सएमएल को पाठ के कभी-कभी स्पष्ट खंड के साथ स्पष्ट रूप से यादृच्छिक कचरा के रूप में वापस कर दिया जाएगा। असल में, अगर मुझे लगता है कि 256 के बाद सभी वर्णों के लिए क्वेरी यादृच्छिक ब्लॉक लौटाती है।

मेरे विशिष्ट मामले में, मैं एक वेबसाइट पर भेजने के लिए एक्सएमएल (एक्सएमएल नेस्टेड प्रश्नों के लिए एकाधिक का उपयोग कर) उत्पन्न कर रहा था प्रदर्शन।इस मामले में, मुझे जो समाधान मिला वह सीएएसटी हैक का उपयोग करना था, जिससे डेटा को वर्चर (अधिकतम) में कास्टिंग किया गया था।

तो याद रखें: यदि आप अपने क्वेरी परिणामों में यादृच्छिक कचरा के बाद 256 स्पष्ट वर्णों का एक ब्लॉक देखते हैं, तो शायद यह एक एक्सएमएल मान वर्चर (अधिकतम) प्रकार के बजाय एक्सएमएल प्रकार के रूप में लौटाया जा रहा है।

कैवेट: यह केवल तब लागू हो सकता है जब एक्सएमएल गतिशील रूप से उत्पन्न हो।