समस्या निवारण "टकराव का अवैध मिश्रण" mysql में त्रुटि

Question

MySQL में एक संग्रहीत प्रक्रिया के माध्यम से चयन करने की कोशिश करते समय नीचे त्रुटि हो रही है।

टकरावों का अवैध मिश्रण (लैटिन 1_जेनर_क्स, IMPLICIT) और ऑपरेशन के लिए (latin1_general_ci, IMPLICIT) '='

यहाँ क्या गलत हो सकता है पर कोई विचार?

तालिका का टकराव latin1_general_ciउस स्तंभ का है और जहां खंड है latin1_general_cs।

Comments

मैं बड़ी अवधि (1990 से) के लिए विभिन्न प्रकार के डेटाबेस का उपयोग कर रहा हूं, और NySQL द्वारा बनाए गए कॉलेशन a cod coercibiity का उपयोग "पागल" के रूप में प्रकट होता है, डेटाबेस डेटाबेस के लिए "एक" वर्ण सेट करने वाली समस्याओं को हल करता है, फिर ऊपर है डेटाबेस द्वारा उपयोग किए गए अनन्य वर्ण सेट से / से परिवर्तित करने के लिए आयात / निर्यात प्रक्रिया। Mysql चुना समाधान एक विघटित है, क्योंकि डेटाबेस के मुद्दे (टकराने का उपयोग) के साथ "आवेदन मुद्दों" (चरित्र सेट रूपांतरण) का मिश्रण है। क्यों नहीं "हटाने" कि मूर्खतापूर्ण और बोझिल डेटाबेस से सुविधाएँ तो यह बहुत अधिक प्रयोग करने योग्य और नियंत्रणीय हो जाता है

— मॉरीज़ियो पिओवियोली

Answer 1

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

खंड COLLATEआपको क्वेरी में उपयोग किए गए कोलाज को निर्दिष्ट करने की अनुमति देता है।

उदाहरण के लिए, निम्न WHEREक्लॉज हमेशा आपके द्वारा पोस्ट की गई त्रुटि देगा:

WHERE 'A' COLLATE latin1_general_ci = 'A' COLLATE latin1_general_cs

आपका समाधान क्वेरी के भीतर दो कॉलम के लिए एक साझा कोलाज निर्दिष्ट करना है। यहाँ एक उदाहरण दिया गया है जो COLLATEखंड का उपयोग करता है :

SELECT * FROM table ORDER BY key COLLATE latin1_general_ci;

एक अन्य विकल्प BINARYऑपरेटर का उपयोग करना है:

BINARY str, CAST (str AS BINARY) के लिए शॉर्टहैंड है।

आपका समाधान कुछ इस तरह दिख सकता है:

SELECT * FROM table WHERE BINARY a = BINARY b;

या,

SELECT * FROM table ORDER BY BINARY a;

Comments

धन्यवाद। वास्तव में यह मेरे मामले में बहुत अजीब व्यवहार कर रहा है। जब मैं क्वेरी को चलाता हूं, तो क्वेरी ब्राउज़र के माध्यम से, यह मुझे परिणाम देता है। लेकिन एक संग्रहीत प्रक्रिया का उपयोग करके एक त्रुटि होती है।

— user355562

बाइनरी मेरे लिए सबसे अच्छा समाधान लग रहा था। यह आपके लिए सबसे अच्छा हो सकता है यदि आप किसी भी मुश्किल फ़िल्टर का उपयोग नहीं कर रहे हैं।

— एडम एफ

मेरे पास एक ही मुद्दा है, जिस तरह से मैं इस समस्या को हल करता हूं वह शुरुआत से फिर से बना है। मैंने कोलाज बदलने की कोशिश की, लेकिन जब मैं ज्वाइन करता हूं तब भी एक त्रुटि होती है, इसलिए मैंने इस तरह से कोशिश की। सेमीइवी

— बॉबी जेड

कृपया ध्यान दें कि MariaDB में एक बग है, COLLATE latin1_general_ci जिसके उपयोग से एक और त्रुटि होती है: COLLATION 'utf8_general_ci' is not valid for CHARACTER SET 'latin1''- भले ही आपके पास CHARACTER SET 'latin1' वाला कॉलम न हो! समाधान BINARY कलाकारों का उपयोग करना है। यह प्रश्न

— Mel_T

Answer 2

टी एल; डॉ

या तो तार के एक (या दोनों) के टकराव को बदल दें ताकि वे मेल खाते हों, या फिर COLLATEआपकी अभिव्यक्ति में एक खंड जोड़ दें ।

---

1. वैसे भी यह "कॉलेशन" सामान क्या है?

   जैसा कि जनरल में कैरेक्टर सेट और कोलाज के तहत प्रलेखित है :

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

   मान लीजिए कि हमारे पास चार अक्षरों के साथ एक वर्णमाला है: " A", " B", " a", " b"। हम प्रत्येक अक्षर को एक नंबर देते हैं: " A" = 0, " B" = 1, " a" = 2, " b" = 3. पत्र " A" एक प्रतीक है, संख्या 0 " एन्कोडिंगA " और सभी के संयोजन के लिए है चार अक्षर और उनका एनकोडिंग एक चरित्र सेट है ।

   मान लीजिए कि हम दो स्ट्रिंग मानों की तुलना करना चाहते हैं, " A" और " B"। ऐसा करने का सबसे सरल तरीका एन्कोडिंग: 0 के लिए " A" और "के लिए B" है। क्योंकि 0 1 से कम है, हम कहते हैं कि " A" से कम है B। हमने जो कुछ किया है, वह हमारे चरित्र सेट से टकराव पर लागू होता है। टकराव नियमों का एक समूह है (इस मामले में केवल एक नियम): "एन्कोडिंग की तुलना करें।" हम सभी संभव कोलाज के इस सबसे सरल कॉल को एक बाइनरी कॉलेशन कहते हैं।

   लेकिन क्या होगा अगर हम कहना चाहते हैं कि लोअरकेस और अपरकेस अक्षर बराबर हैं? फिर हम कम से कम दो नियम होता है: (1) छोटे अक्षरों "इलाज a" और " b" समकक्ष के रूप में करने के लिए " A" और " B"; (२) फिर एनकोडिंग की तुलना करें। हम इसे केस-असंवेदनशील टकराव कहते हैं। यह बाइनरी कॉलेशन की तुलना में थोड़ा अधिक जटिल है।

   वास्तविक जीवन में, अधिकांश चरित्र सेटों में कई वर्ण होते हैं: न केवल " A" और " B" बल्कि पूरे वर्णमाला, कभी-कभी कई वर्णों के साथ कई वर्णमाला या पूर्वी लेखन प्रणाली, साथ ही कई विशेष प्रतीकों और विराम चिह्नों के साथ। वास्तविक जीवन में भी, अधिकांश टकरावों के कई नियम होते हैं, न कि केवल अक्षर भेद करने के लिए, बल्कि यह भी कि क्या उच्चारणों में अंतर करना है ("उच्चारण", जर्मन में "वर्ण" से जुड़ा हुआ चिह्न है Ö), और कई-वर्णों के लिए मैपिंग (जैसे कि नियम है कि " Ö" = " OE" दो जर्मन समागमों में से एक में)।

   इसके और उदाहरण कोलम्बेशन के प्रभाव के उदाहरण के तहत दिए गए हैं ।

2. ठीक है, लेकिन MySQL यह कैसे तय करता है कि किसी दिए गए एक्सप्रेशन के लिए कौन सा कोलाज इस्तेमाल किया जाए?

   अभिव्यक्ति के टकराव के तहत प्रलेखित :

   बयानों के महान बहुमत में, यह स्पष्ट है कि एक तुलना ऑपरेशन को हल करने के लिए MySQL का उपयोग क्या है। उदाहरण के लिए, निम्नलिखित मामलों में, यह स्पष्ट होना चाहिए कि टकराव स्तंभ का टकराव है charset_name:

   SELECT x FROM T ORDER BY x;
   SELECT x FROM T WHERE x = x;
   SELECT DISTINCT x FROM T;
   

   हालांकि, कई ऑपरेंड के साथ अस्पष्टता हो सकती है। उदाहरण के लिए:

   SELECT x FROM T WHERE x = 'Y';

   तुलना का उपयोग कॉलम के टकराव का होना चाहिए x, या स्ट्रिंग शाब्दिक का 'Y'? दोनों xऔर 'Y'टकराव होते हैं, इसलिए कौन सा टकराव पूर्वता लेता है?

   मानक एसक्यूएल ऐसे प्रश्नों को हल करता है, जिनका उपयोग "कोऑर्किबिलिटी" नियम कहा जाता है।

   [ विलोप ]

   MySQL अस्पष्टता को हल करने के लिए निम्नलिखित नियमों के साथ सह-संयम मूल्यों का उपयोग करता है:

   • सबसे कम coercibility मूल्य के साथ टकराव का उपयोग करें।

   • यदि दोनों पक्षों में एक समान सामंजस्य है, तो:

     • यदि दोनों पक्ष यूनिकोड हैं, या दोनों पक्ष यूनिकोड नहीं हैं, तो यह एक त्रुटि है।

     • यदि किसी एक पक्ष में एक यूनिकोड वर्ण सेट है, और दूसरे पक्ष में एक गैर-यूनिकोड वर्ण सेट है, तो यूनिकोड वर्ण सेट जीत के साथ पक्ष है, और स्वचालित चरित्र सेट रूपांतरण गैर-यूनिकोड पक्ष पर लागू होता है। उदाहरण के लिए, निम्नलिखित कथन में कोई त्रुटि नहीं है:

       SELECT CONCAT(utf8_column, latin1_column) FROM t1;

       यह एक परिणाम देता है जिसमें एक वर्ण सेट होता है utf8और उसी के समान टकराव होता है utf8_column। मानों latin1_columnको स्वतः समाप्‍त करने utf8से पहले रूपांतरित किया जाता है।

     • एक ही वर्ण सेट से ऑपरेंड के साथ एक ऑपरेशन के लिए, लेकिन यह एक मिश्रण _binमिलान और एक _ciया _csमिलान, _binमिलान किया जाता है। यह उसी तरह से है जैसे ऑपरेशन जो कि नॉनबिनाइक और बाइनरी स्ट्रिंग्स को मिलाते हैं, ऑपरेशंस को बाइनरी स्ट्रिंग्स के रूप में मूल्यांकन करते हैं, सिवाय इसके कि यह डेटा प्रकारों के बजाय टकराव के लिए है।

3. तो "टकरावों का अवैध मिश्रण" क्या है?

   "टकरावों का अवैध मिश्रण" तब होता है जब कोई अभिव्यक्ति अलग-अलग टकरावों के दो तारों की तुलना करती है लेकिन समान सहिष्णुता और समन्वयता के नियम संघर्ष को हल करने में मदद नहीं कर सकते। यह उपरोक्त उद्धरण में तीसरे बुलेट-पॉइंट के तहत वर्णित स्थिति है।

   प्रश्न में दी गई विशेष त्रुटि Illegal mix of collations (latin1_general_cs,IMPLICIT) and (latin1_general_ci,IMPLICIT) for operation '=', हमें बताती है कि समान सह-संयम के दो गैर-यूनिकोड तारों के बीच समानता की तुलना थी। यह आगे हमें बताता है कि बयानों में स्पष्ट रूप से टकराव नहीं दिए गए थे, बल्कि तार के स्रोतों (जैसे स्तंभ मेटाडेटा) से निहित थे।

4. यह सब बहुत अच्छा है, लेकिन कोई व्यक्ति ऐसी त्रुटियों को कैसे हल करता है?

   जैसा कि ऊपर दिए गए मैनुअल अर्क सुझाव से पता चलता है, इस समस्या को कई तरीकों से हल किया जा सकता है, जिनमें से दो समझदार हैं और अनुशंसित होने के लिए:

   • स्ट्रिंग्स के एक (या दोनों) के मिलान को बदलें ताकि वे मेल खाते हों और अब कोई अस्पष्टता नहीं है।

     यह कैसे किया जा सकता है यह इस बात पर निर्भर करता है कि स्ट्रिंग कहाँ से आई है: शाब्दिक भाव collation_connectionसिस्टम चर में निर्दिष्ट टकराव को लेते हैं ; तालिकाओं से मान उनके कॉलम मेटाडेटा में निर्दिष्ट टकराव को लेते हैं।

   • एक स्ट्रिंग को जबरदस्ती न करने के लिए मजबूर करें।

     मैंने उपरोक्त उद्धरण को छोड़ दिया है:

     MySQL इस प्रकार के रूप में सहक्रियाशीलता मूल्य प्रदान करता है:

     • एक स्पष्ट COLLATEक्लॉज़ में 0. की सह-सक्रियता होती है (बिल्कुल भी ज़बर्दस्ती नहीं।)

     • अलग-अलग समतलों के साथ दो तारों के संघनन में 1 की सहसंयोजकता होती है।

     • एक स्तंभ या एक संग्रहीत नियमित पैरामीटर या स्थानीय चर के टकराने से 2 की एक सहसंयोजकता होती है।

     • एक "सिस्टम स्थिरांक" (जैसे USER()या जैसे फ़ंक्शंस द्वारा लौटाए गए तार VERSION()में 3 की सह-क्षमता होती है।

     • शाब्दिक रूप से टकराने पर 4 की एक सहकर्मी क्षमता होती है।

     • NULLया जो एक अभिव्यक्ति से लिया गया NULLहै, उसमें 5 की सह-क्षमता है।

     इस प्रकार COLLATEतुलना में उपयोग किए गए स्ट्रिंग्स में से एक क्लॉज को जोड़ने से उस कॉलेशन का उपयोग करने के लिए मजबूर हो जाएगा।

   यदि इस त्रुटि को हल करने के लिए केवल तैनात किया गया था, तो दूसरों को बहुत बुरा अभ्यास होगा:

   • स्ट्रिंग्स के एक (या दोनों) को कुछ अन्य सह-संयम मूल्य रखने के लिए बाध्य करें ताकि एक पूर्वता ले।

     का उपयोग करने CONCAT()या CONCAT_WS()एक स्ट्रिंग में परिणाम होगा 1 की सहकर्मी क्षमता के साथ; और (यदि एक संग्रहित दिनचर्या में) मापदंडों / स्थानीय चरों के उपयोग से तार 2 के सह-संयोजन से उत्पन्न होंगे।

   • स्ट्रिंग्स के एक (या दोनों) के एनकोडिंग को बदलें ताकि एक यूनिकोड हो और दूसरा न हो।

     इसके साथ ट्रांसकोडिंग के माध्यम से किया जा सकता है ; या डेटा के अंतर्निहित वर्ण सेट को बदलने के माध्यम से (उदाहरण के लिए स्तंभ को संशोधित करना, शाब्दिक मूल्यों के लिए बदलना , या उन्हें क्लाइंट से एक अलग एन्कोडिंग में भेजना और चरित्र सेट परिचयकर्ता को बदलना / जोड़ना)। ध्यान दें कि एन्कोडिंग को बदलने से अन्य समस्याएं हो सकती हैं यदि कुछ वांछित वर्णों को नए वर्ण सेट में एन्कोड नहीं किया जा सकता है।CONVERT(expr USING transcoding_name)character_set_connectioncharacter_set_client

   • स्ट्रिंग्स के एक (या दोनों) के एन्कोडिंग को बदलें ताकि वे दोनों समान हों और संबंधित _binटकराव का उपयोग करने के लिए एक स्ट्रिंग को बदल दें ।

     एन्कोडिंग और कोलाज को बदलने के तरीके ऊपर दिए गए हैं। इस दृष्टिकोण का बहुत कम उपयोग होगा यदि किसी को वास्तव में अधिक उन्नत कोलाजेशन नियमों को लागू करने की आवश्यकता होती है, जो _binकोलाज द्वारा प्रस्तुत की जाती है ।

Comments

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

— अर्ग्युअल

बहुत बढ़िया जवाब। यह आगे होना चाहिए, क्योंकि यह गोताखोरों को वास्तव में पता होना चाहिए; न केवल इसे ठीक करने के लिए, बल्कि वास्तव में समझें कि चीजें किस तरह से हो रही हैं?

— चिह्नित करें

धन्यवाद दोस्त, आपने आज मुझे कुछ सिखाया है।

— briankip

Answer 3

भविष्य के गुगलों के लिए चर्चा में मेरा 2 सी जोड़ना।

मैं एक ऐसे ही मामले की जांच कर रहा था जहां मुझे कस्टम फ़ंक्शंस का उपयोग करते समय निम्नलिखित त्रुटि मिली थी जो कि एक varchar पैरामीटर को पुन: प्राप्त करता है:

Illegal mix of collations (utf8_unicode_ci,IMPLICIT) and 
(utf8_general_ci,IMPLICIT) for operation '='

निम्नलिखित क्वेरी का उपयोग करना:

mysql> show variables like "collation_database";
    +--------------------+-----------------+
    | Variable_name      | Value           |
    +--------------------+-----------------+
    | collation_database | utf8_general_ci |
    +--------------------+-----------------+

मैं यह बताने में सक्षम था कि DB utf8_general_ci का उपयोग कर रहा था , जबकि तालिका utf8_unicode_ci का उपयोग करके परिभाषित की गई थी :

mysql> show table status;
    +--------------+-----------------+
    | Name         | Collation       |
    +--------------+-----------------+
    | my_view      | NULL            |
    | my_table     | utf8_unicode_ci |
    ...

सूचना का नजारा दिखता है कि शून्य मिलान। ऐसा प्रतीत होता है कि विचारों और कार्यों में टकराव की परिभाषाएँ हैं भले ही यह क्वेरी एक दृश्य के लिए अशक्त दिखती हो। उपयोग किया गया कोलाजेशन डीबी कोलाजेशन है जिसे व्यू / फंक्शन बनाते समय परिभाषित किया गया था।

दु: खद समाधान दोनों डीबी कोलेशन को बदलना और वर्तमान टकराव का उपयोग करने के लिए मजबूर करने के लिए विचारों / कार्यों को फिर से बनाना था।

• डीबी की टक्कर को बदलना:

  ALTER DATABASE mydb DEFAULT COLLATE utf8_unicode_ci;

• तालिका में परिवर्तन:

  ALTER TABLE mydb CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

मुझे उम्मीद है कि यह किसी की मदद करेगा।

Comments

स्तंभ स्तर पर टकराना भी सेट किया जा सकता है। आप इसे देख सकते हैं:show full columns from my_table;

— जोनाथन ट्रैन

धन्यवाद। मैंने बस स्कीमा को गिरा दिया, और इसे सही डिफ़ॉल्ट टकराव के साथ फिर से बनाया, और सब कुछ फिर से आयात किया।

— JRun

@JonathanTran धन्यवाद! मेरे पास सभी तालिकाओं, डेटाबेस और कनेक्शन पर वर्ण सेट और कोलाज सेट था, लेकिन यह अभी भी एक त्रुटि दे रहा था! टकराव एक स्तंभ पर सेट नहीं किया गया था! मैंने इसे तय कियाalter table <TABLE> modify column <COL> varchar(255) collate utf8_general_ci;

— क्लो

भविष्य के गोगलर्स के लिए सिडेनोट: भले ही आपके डेटाबेस, टेबल और फील्ड सभी में समान टकराव हो, आपको यह भी सुनिश्चित करना होगा कि आपका कनेक्शन समान कोलेशन का उपयोग कर रहा है। सब कुछ »utf8mb4_unicode_ci« है लेकिन SHOW session variables like '%collation%';आपको बताता है कि »collation_connection« »» utf8mb4_general_ci «है? फिर SET collation_connection = utf8mb4_unicode_ciपहले से चलाएं ।

— pixelbrackets

धन्यवाद! इसे नीचे ट्रैक करने के लिए मुझे कुछ समय लगा। न केवल तालिकाओं को एक ही टकराव होना चाहिए, लेकिन डीबी भी करता है!

— मोटो

Answer 4

कभी-कभी यह विशेष रूप से बड़ी मात्रा में डेटा के साथ डेटाबेस पर चार्ट को बदलना खतरनाक हो सकता है। मुझे लगता है कि सबसे अच्छा विकल्प "बाइनरी" ऑपरेटर का उपयोग करना है:

e.g : WHERE binary table1.column1 = binary table2.column1

Answer 5

मुझे एक समान समस्या थी, एक स्ट्रिंग चर के साथ FIND_IN_SET प्रक्रिया का उपयोग करने की कोशिश कर रहा था ।

SET @my_var = 'string1,string2';
SELECT * from my_table WHERE FIND_IN_SET(column_name,@my_var);

और त्रुटि प्राप्त कर रहा था

त्रुटि कोड: 1267. ऑपरेशन 'find_in_set' के लिए कोलाज का अवैध मिश्रण (utf8_unicode_ci, IMPLICIT) और (utf8_general_ci, IMPLICIT)

संक्षिप्त जवाब:

किसी भी collation_YYYY चर को बदलने की आवश्यकता नहीं है, बस अपने चर घोषणा के बगल में सही कोलाजेशन जोड़ें , अर्थात

SET @my_var = 'string1,string2' COLLATE utf8_unicode_ci;
SELECT * from my_table WHERE FIND_IN_SET(column_name,@my_var);

लंबा जवाब:

मैंने पहली बार टकराव चर की जाँच की:

mysql> SHOW VARIABLES LIKE 'collation%';
    +----------------------+-----------------+
    | Variable_name        | Value           |
    +----------------------+-----------------+
    | collation_connection | utf8_general_ci |
    +----------------------+-----------------+
    | collation_database   | utf8_general_ci |
    +----------------------+-----------------+
    | collation_server     | utf8_general_ci |
    +----------------------+-----------------+

फिर मैंने टेबल कोलाज की जाँच की:

mysql> SHOW CREATE TABLE my_table;

CREATE TABLE `my_table` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `column_name` varchar(40) COLLATE utf8_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=125 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

इसका मतलब यह है कि मेरे चर को utf8_general_ci के डिफ़ॉल्ट टकराव के साथ कॉन्फ़िगर किया गया था, जबकि मेरी तालिका utf8_unicode_ci के रूप में कॉन्फ़िगर की गई थी ।

चर घोषणा के बगल में COLLATE कमांड जोड़कर, चर कोलाजेशन ने तालिका के लिए कॉन्फ़िगर किए गए टकराव का मिलान किया।

Answer 6

आप इस स्क्रिप्ट को आज़मा सकते हैं , जो आपके सभी डेटाबेस और तालिकाओं को utf8 में बदल देता है।

Comments

लाइन "कर्सर" के बजाय 24 "

— कर्व

और कुछ इंडेक्स के आकार को ट्राइ करता है।

— डेमियन यरिक 12

Answer 7

समाधान अगर शाब्दिक शामिल हैं।

मैं Pentaho डेटा एकीकरण का उपयोग कर रहा हूँ और न ही sql सिंटैक्स निर्दिष्ट करने के लिए मिलता है। डीबी लुकअप का उपयोग करते हुए त्रुटि "ऑपरेशन के लिए" = "" कोलाज का अवैध मिश्रण (cp850_general_ci, COERCIBLE) और (लैटिन 1_स्विक_का, COERCIBLE) दिया गया।

जनरेट कोड "SELECT DATA_DATE AS के नवीनतम_DATA_DATE से hr_cc_normalised_data_date_v PSEUDO_KEY =?"

लघुकथा को काटकर देखना एक नज़रिया था और जब मैंने जारी किया

mysql> show full columns from hr_cc_normalised_data_date_v;
+------------+------------+-------------------+------+-----+
| Field      | Type       | Collation         | Null | Key |
+------------+------------+-------------------+------+-----+
| PSEUDO_KEY | varchar(1) | cp850_general_ci  | NO   |     |
| DATA_DATE  | varchar(8) | latin1_general_cs | YES  |     |
+------------+------------+-------------------+------+-----+

जो बताता है कि 'cp850_general_ci' कहाँ से आता है।

यह दृश्य केवल 'SELECT' X ', ......' के साथ बनाया गया था, इस तरह से मैनुअल शाब्दिक के अनुसार इस तरह से उनके चरित्र सेट और सर्वर सेटिंग्स से टकराव होना चाहिए, जिन्हें सही ढंग से 'latin1' और 'latin1_general_cs' के रूप में परिभाषित किया गया था स्पष्ट रूप से ऐसा नहीं हुआ मैंने इसे देखने के निर्माण में मजबूर किया

CREATE OR REPLACE VIEW hr_cc_normalised_data_date_v AS
SELECT convert('X' using latin1) COLLATE latin1_general_cs        AS PSEUDO_KEY
    ,  DATA_DATE
FROM HR_COSTCENTRE_NORMALISED_mV
LIMIT 1;

अब यह दोनों स्तंभों के लिए latin1_general_cs दिखाता है और त्रुटि दूर हो गई है। :)

Answer 8

MySQL वास्तव में टकराव को नापसंद करता है जब तक कि यह उन्हें एक ही (जो आपके मामले में स्पष्ट रूप से संभव नहीं है) के लिए मजबूर कर सकता है। क्या आप केवल कोलाज़ क्लॉज़ के माध्यम से उपयोग किए जाने वाले समान कोलेशन को बाध्य नहीं कर सकते हैं ? (या सरल BINARYशॉर्टकट लागू होने पर ...)।

Comments

क्या यह MySQL के लिए अद्वितीय है? अन्य प्रणालियां स्पष्ट रूप से समान प्राथमिकता के असंगत टकरावों के मिश्रण को कैसे संभालती हैं?

— अर्ग्युअल

आपका लिंक मान्य नहीं है।

— बेनुबर्ड

Answer 9

यदि आप जिन स्तंभों से परेशान हैं, वे "हैश" हैं, तो निम्नलिखित पर विचार करें ...

यदि "हैश" एक द्विआधारी स्ट्रिंग है, तो आपको वास्तव में BINARY(...)डेटाटाइप का उपयोग करना चाहिए ।

यदि "हैश" एक हेक्स स्ट्रिंग है, तो आपको utf8 की आवश्यकता नहीं है, और चरित्र जांच आदि के कारण ऐसे से बचना चाहिए। उदाहरण के लिए, MySQL की MD5(...)पैदावार एक निश्चित लंबाई 32-बाइट हेक्स स्ट्रिंग है। SHA1(...)एक 40-बाइट हेक्स स्ट्रिंग देता है। इसे CHAR(32) CHARACTER SET ascii(या sha1 के लिए 40) में संग्रहीत किया जा सकता है ।

या, बेहतर अभी तक, स्टोर UNHEX(MD5(...))में BINARY(16)। यह स्तंभ के आधे आकार में कटौती करता है। (हालांकि, SELECT HEX(hash) ...अगर आप इसे पठनीय चाहते हैं , तो इसे अप्राप्य बना दें।)

दो BINARYस्तंभों की तुलना में कोई टकराव की समस्या नहीं है।

Answer 10

बहुत दिलचस्प ... अब, तैयार रहिए। मैंने सभी "ऐड कोलाट" समाधानों को देखा और मेरे लिए, वे बैंड सहायता फिक्स हैं। वास्तविकता यह है कि डेटाबेस डिजाइन "खराब" था। हां, मानक परिवर्तन और नई चीजें जुड़ जाती हैं, ब्ला ब्ला, लेकिन यह खराब डेटाबेस डिजाइन तथ्य को नहीं बदलता है। मैं सिर्फ काम करने के लिए अपनी क्वेरी प्राप्त करने के लिए सभी एसक्यूएल बयानों पर "कोलाट" जोड़ने के मार्ग के साथ जाने से इनकार करता हूं। एकमात्र समाधान जो मेरे लिए काम करता है और भविष्य में मेरे कोड को मोड़ने की आवश्यकता को समाप्त कर देगा, चरित्र सेट से मिलान करने के लिए डेटाबेस / तालिकाओं को फिर से डिजाइन करना है जिसे मैं भविष्य के लिए और दीर्घकालिक भविष्य के लिए गले लगाऊंगा। इस मामले में, मैं " utf8mb4 " चरित्र सेट के साथ जाना पसंद करता हूं ।

तो यहाँ समाधान जब आप मुठभेड़ करते हैं कि "अवैध" त्रुटि संदेश आपके डेटाबेस और तालिकाओं को फिर से डिजाइन करना है। यह बहुत आसान है और जल्दी है तो यह लगता है। अपना डेटा निर्यात करना और इसे CSV से फिर से आयात करना भी आवश्यक नहीं हो सकता है। डेटाबेस के वर्ण सेट को बदलें और सुनिश्चित करें कि आपके टेबल के सभी वर्ण सेट मेल खाते हैं।

आपका मार्गदर्शन करने के लिए इन कमांड का उपयोग करें:

SHOW VARIABLES LIKE "collation_database";
SHOW TABLE STATUS;

अब, अगर आपको यहां और वहां "कोलायत" जोड़ने का आनंद मिलता है, और फोर्स फुल "ओवरराइड्स" के साथ अपना कोड गोमांस करें, तो मेरा अनुमान है।

Answer 11

एक संभावित समाधान पूरे डेटाबेस को UTF8 में परिवर्तित करना है (यह प्रश्न भी देखें )।

Answer 12

समतलीकरण के साथ समस्या का एक अन्य स्रोत mysql.procतालिका है। अपनी भंडारण प्रक्रियाओं और कार्यों की जाँच करें:

SELECT
  p.db, p.db_collation, p.type, COUNT(*) cnt
FROM mysql.proc p
GROUP BY p.db, p.db_collation, p.type;

कॉलम mysql.proc.collation_connectionऔर mysql.proc.character_set_clientकॉलम पर भी ध्यान दें ।

Answer 13

यदि आपके पास phpMyAdmin स्थापित है, तो आप निम्न लिंक में दिए गए निर्देशों का पालन कर सकते हैं: https://mediatemple.net/community/products/dv/204403914/default-mysql-character-set-collation - आपको कोलाट से मिलान करना होगा डेटाबेस के सभी तालिकाओं के साथ ही तालिकाओं के क्षेत्र और फिर सभी संग्रहीत प्रक्रियाओं और कार्यों को फिर से इकट्ठा करना। इसके साथ ही सब कुछ फिर से काम करना चाहिए।

Answer 14

मैंने इस्तेमाल किया ALTER DATABASE mydb DEFAULT COLLATE utf8_unicode_ci;, लेकिन काम नहीं किया।

इस प्रश्न में:

Select * from table1, table2 where table1.field = date_format(table2.field,'%H');

मेरे लिए यह काम:

Select * from table1, table2 where concat(table1.field) = date_format(table2.field,'%H');

हाँ, केवल ए concat।

Comments

अपनी तालिकाओं और उनके स्तंभों के मिलान की जाँच करें (तालिका स्थिति दिखाएं; और तालिका 1 से पूर्ण स्तंभ दिखाएं;)। यदि पहले से ही गलत कॉलेशन के साथ टेबल बनाए गए हैं, तो डेटाबेस में परिवर्तन का उपयोग करना काम नहीं करेगा।

— एरियल टी

हमेशा के लिए mydb DEFAULT COLLATE ... मेरे लिए काम किया है, इसलिए upvote। शायद मेरे पास एक फायदा था क्योंकि मैं डेटाबेस को छोड़ सकता था और बैकअप से पुनः लोड कर सकता था।

— टोबिक्सेन

Answer 15

इस कोड को डेटाबेस में Run SQL क्वेरी / क्वेरी के अंदर रखा जाना चाहिए

SQL QUERY विन्डोज़

ALTER TABLE `table_name` CHANGE `column_name` `column_name`   VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL;

कृपया उपयुक्त नाम के साथ table_name और column_name बदलें।