MySQL गलत डेटाइम मान: '0000-00-00 00:00:00'

155

मैंने हाल ही में 10 साल पहले बनाई गई एक पुरानी परियोजना को संभाला है। इसमें MySQL 5.1 का उपयोग किया गया है।

अन्य बातों के अलावा, मुझे लैटिन 1 से utf8 तक तयशुदा चरित्र को बदलना होगा।

एक उदाहरण के रूप में, मेरे पास इस तरह की तालिकाएँ हैं:

  CREATE TABLE `users` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    `first_name` varchar(45) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT NULL,
    `last_name` varchar(45) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT NULL,
    `username` varchar(127) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL,
    `email` varchar(127) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL,
    `pass` varchar(20) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL,
    `active` char(1) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT 'Y',
    `created` datetime NOT NULL,
    `last_login` datetime DEFAULT NULL,
    `author` varchar(1) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT 'N',
    `locked_at` datetime DEFAULT NULL,
    `created_at` datetime DEFAULT NULL,
    `updated_at` datetime DEFAULT NULL,
    `ripple_token` varchar(36) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT NULL,
    `ripple_token_expires` datetime DEFAULT '2014-10-31 08:03:55',
    `authentication_token` varchar(255) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT NULL,
    PRIMARY KEY (`id`),
    UNIQUE KEY `index_users_on_reset_password_token` (`reset_password_token`),
    UNIQUE KEY `index_users_on_confirmation_token` (`confirmation_token`),
    UNIQUE KEY `index_users_on_unlock_token` (`unlock_token`),
    KEY `users_active` (`active`),
    KEY `users_username` (`username`),
    KEY `index_users_on_email` (`email`)
  ) ENGINE=InnoDB AUTO_INCREMENT=1677 DEFAULT CHARSET=utf8 CHECKSUM=1 DELAY_KEY_WRITE=1 ROW_FORMAT=DYNAMIC

मैंने इस पर काम करने के लिए अपना स्वयं का मैक स्थापित किया। इसके बारे में बहुत अधिक सोचने के बिना, मैंने "ब्रुअ इंस्टॉल मायस्कल" चलाया, जिसने MySQL 5.7 स्थापित किया। इसलिए मेरे पास कुछ संस्करण संघर्ष हैं।

मैंने इस डेटाबेस की एक प्रति डाउनलोड की और इसे आयात किया।

अगर मैं इस तरह एक क्वेरी चलाने की कोशिश करता हूं:

  ALTER TABLE users MODIFY first_name varchar(45) CHARACTER SET utf8 COLLATE utf8_general_ci    NOT NULL

मुझे यह त्रुटि मिली:

  ERROR 1292 (22007): Incorrect datetime value: '0000-00-00 00:00:00' for column 'created' at row 1

मुझे लगा कि मैं इसे ठीक कर सकता हूं:

  ALTER TABLE users MODIFY created datetime  NULL DEFAULT '1970-01-01 00:00:00';
  Query OK, 0 rows affected (0.06 sec)
  Records: 0  Duplicates: 0  Warnings: 0

लेकिन मुझे मिलता है:

  ALTER TABLE users MODIFY first_name varchar(45) CHARACTER SET utf8 COLLATE utf8_general_ci    NOT NULL ;
  ERROR 1292 (22007): Incorrect datetime value: '0000-00-00 00:00:00' for column 'created' at row 1

क्या मुझे हर मूल्य को अपडेट करना है?

mysql

— Lorm
स्रोत

12

मेरा सुझाव यदि यह मामला है कि तालिका खाली है या बहुत बड़ी नहीं है, तो एक .sql फ़ाइल के रूप में निर्मित कथनों को निर्यात करें, उन्हें अपनी इच्छानुसार फिर से लिखें। यदि आपके पास कोई मौजूदा डेटा है, अर्थात निर्यात सम्मिलित कथन (मैं बनाएँ बयानों के रूप में एक अलग फ़ाइल में ऐसा करने की सलाह देता हूं) भी ऐसा ही करें। अंत में, तालिका को छोड़ें और पहले स्टेटमेंट बनाएं और फिर आवेषण करें।

आप mysqldumpअपने MySQL इंस्टॉलेशन में शामिल उस कमांड के लिए उपयोग कर सकते हैं या आप MySQL वर्कबेन्च को भी इंस्टॉल कर सकते हैं, जो कि एक फ्री ग्राफिकल टूल है जिसमें विशिष्ट कमांड विकल्पों की तलाश किए बिना भी इस विकल्प को बहुत ही अनुकूलन योग्य तरीके से शामिल किया गया है।

— लूसिया पसरीन
स्रोत

लूसिया पसारिन, मुझे आपका विचार बहुत पसंद है, लेकिन क्या डेटा छोटा नहीं होगा? क्या कुछ UTF8 डेटा लैटिन 1 से अधिक बाइट्स लेते हैं? अगर कुछ पहले varchar 255 में फिट होता है, तो शायद अब यह नहीं होगा? क्या मुझे, शायद, सभी varchars को "text" फ़ील्ड में बदलना चाहिए?

— 23

हाँ आप सही है। ऐसा तब से हो सकता है जब लैटिन 1 प्रति चार बाइट का उपयोग करता है, जबकि utf8 प्रति चार्ट में 4 बाइट्स का उपयोग करता है (MySQL के संस्करण के आधार पर और utf8 dev.mysql.com/doc/refman/5.5/en=charset-unicode के प्रकार पर) -utf8.html )। इसलिए, आपको आवश्यक रूप से TEXT प्रकार की आवश्यकता नहीं है। मुझे लगता है कि x4 अपने पहले से मौजूद आकार काम करना चाहिए।

— लुसिया पसरीन

जब आप किसी फ़ाइल को हटाना चाहते हैं तो यह आपकी हार्ड ड्राइव को पुन: स्वरूपित करने के बराबर डेटाबेस है। यह कहना सुरक्षित है कि यह समाधान उत्पादन वातावरण में स्वीकार्य नहीं है।

— ब्रैंडन

198

मैं ऐसा करने में सक्षम नहीं था:

UPDATE users SET created = NULL WHERE created = '0000-00-00 00:00:00'

(MySQL 5.7.13 पर)।

मैं Incorrect datetime value: '0000-00-00 00:00:00'त्रुटि प्राप्त करता रहा ।

अजीब बात है, यह काम किया SELECT * FROM users WHERE created = '0000-00-00 00:00:00':। मुझे नहीं पता कि पूर्व विफल क्यों है और बाद का काम करता है ... शायद एक MySQL बग?

किसी भी स्थिति में, इस अद्यतन क्वेरी ने काम किया:

UPDATE users SET created = NULL WHERE CAST(created AS CHAR(20)) = '0000-00-00 00:00:00'

— ओबीई
स्रोत

13

मुझे भी यही समस्या थी, लेकिन आखिरी भाग को सिर्फ 0 पर सेट करना मेरे लिए इसे इस तरह तय किया:UPDATE users SET created = NULL WHERE created = '0'

— ब्रायन लीशमैन

चुनें * entityजहां से बनाया गया है = "0000-00-00 00:00:00" ठीक काम करते हैं, लेकिन एक अद्यतन विफल के साथ! मुझे भी यही समस्या थी। @Obe CAST (AS CHAR (20) बनाया)) के समाधान के साथ इसे ठीक करें ... मुझे लगता है कि यह एक बग है।

— क्रिसवेल

44

मेरे लिए यह UPDATE users SET created = NULL WHERE created=0(शून्य के आसपास) के बिना काम किया

— KIR

1

केवल टाइमस्टैम्प के बिना "0000-00-00" तारीख बदलने के लिए, मैंने CHAR (11)

— D.Tate

1

वह शुद्ध प्रतिभा है। यह स्वीकृत उत्तर क्यों नहीं है? केवल टाइमस्टैम्प के बिना न्यूनतम मूल्य 1000-01-01 है। प्रत्येक तिथि विशेषता के लिए इसे डिफ़ॉल्ट मान के रूप में उपयोग करने पर विचार करें जिसे आप खाली छोड़ने का इरादा रखते हैं या 0000-00-00 मूल्य के साथ।

— अरविनाइटिस क्रिस्टोस

155

एक ALTER TABLEबयान के साथ एक कॉलम के लिए डिफ़ॉल्ट मान को बदलना , जैसे

 ALTER TABLE users MODIFY created datetime  NULL DEFAULT '1970-01-02'

... पहले से संग्रहीत किसी भी मान को नहीं बदलता "डिफ़ॉल्ट" मान सम्मिलित की गई पंक्तियों पर लागू होता है, और जिसके लिए स्तंभ के लिए मान की आपूर्ति नहीं की जाती है।

जैसा कि आप त्रुटि का सामना कर रहे हैं, इसलिए संभावना है कि sql_modeआपके सत्र के लिए सेटिंग शामिल है NO_ZERO_DATE।

संदर्भ: http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_no_zero_date

जब आपने "आयात" किया था, तो उस तालिका में INSERT करने वाले SQL कथन एक सत्र में चलाए गए थे जो शून्य तिथियों के लिए अनुमति देते थे।

Sql_mode सेटिंग देखने के लिए:

SHOW VARIABLES LIKE 'sql_mode' ;

-या-

SELECT @@sql_mode ;

जहां तक वर्तमान समस्या को "ठीक" करने का तरीका है, ताकि जब आप ALTER TABLEबयान चलाते हैं तो त्रुटि नहीं होगी ।

कई विकल्प:

1) को बदलने sql_modeको हटाने के द्वारा, शून्य दिनांकों अनुमति देने के लिए NO_ZERO_DATEऔर NO_ZERO_IN_DATE। परिवर्तन को my.cnf फ़ाइल में लागू किया जा सकता है, इसलिए MySQL सर्वर के पुनः आरंभ के बाद, my.cnf में sql_modeचर की शुरुआत की जाएगी।

एक अस्थायी परिवर्तन के लिए, हम एक वैश्विक परिवर्तन की आवश्यकता के बिना, एकल सत्र के साथ सेटिंग को संशोधित कर सकते हैं।

-- save current setting of sql_mode
SET @old_sql_mode := @@sql_mode ;

-- derive a new value by removing NO_ZERO_DATE and NO_ZERO_IN_DATE
SET @new_sql_mode := @old_sql_mode ;
SET @new_sql_mode := TRIM(BOTH ',' FROM REPLACE(CONCAT(',',@new_sql_mode,','),',NO_ZERO_DATE,'  ,','));
SET @new_sql_mode := TRIM(BOTH ',' FROM REPLACE(CONCAT(',',@new_sql_mode,','),',NO_ZERO_IN_DATE,',','));
SET @@sql_mode := @new_sql_mode ;

-- perform the operation that errors due to "zero dates"

-- when we are done with required operations, we can revert back
-- to the original sql_mode setting, from the value we saved
SET @@sql_mode := @old_sql_mode ;

2) createdNULL मानों को अनुमति देने के लिए कॉलम बदलें , और शून्य पंक्तियों को शून्य मानों में बदलने के लिए मौजूदा पंक्तियों को अपडेट करें

3) शून्य तारीखों को मान्य दिनांक में बदलने के लिए मौजूदा पंक्तियों को अपडेट करें

हमें प्रत्येक पंक्ति को अपडेट करने के लिए अलग-अलग स्टेटमेंट चलाने की आवश्यकता नहीं है। हम सभी पंक्तियों को एक ही झपट्टा में अपडेट कर सकते हैं (यह मानते हुए कि यह एक उचित आकार की तालिका है। एक बड़ी तालिका के लिए, विनम्र रोलबैक / पूर्ववत पीढ़ी से बचने के लिए, हम यथोचित आकार के विखंडू में ऑपरेशन कर सकते हैं।)

प्रश्न में, AUTO_INCREMENTतालिका परिभाषा के लिए दिखाया गया मान हमें आश्वस्त करता है कि पंक्तियों की संख्या अत्यधिक नहीं है।

यदि हमने मानों की createdअनुमति देने के लिए पहले से ही कॉलम बदल दिया है NULL, तो हम ऐसा कुछ कर सकते हैं:

UPDATE  `users` SET `created` = NULL WHERE `created` = '0000-00-00 00:00:00'

या, हम उन्हें मान्य तिथि पर सेट कर सकते हैं, उदाहरण के लिए 2 जनवरी, 1970

UPDATE  `users` SET `created` = '1970-01-02' WHERE `created` = '0000-00-00 00:00:00'

(ध्यान दें कि आधी रात जनवरी 1, 1970 (के एक datetime मूल्य '1970-01-01 00:00:00') है एक "शून्य तिथि"। यही कारण है कि होने के लिए मूल्यांकन किया जाएगा'0000-00-00 00:00:00'

— spencer7593
स्रोत

3

हां, यह मेरे लिए काम कर गया। मैंने my.ini फ़ाइल में sql-mode खोजा और NO_ZERO_IN_DATE और NO_ZERO_DATE को निकाल दिया। फिर सेवा को फिर से शुरू किया। धन्यवाद spencer7593!

— मिल्ली

NO_ZERO_DATE को सेट करें: stackoverflow.com/questions/3891896/…

— उपयोगकर्ता 1007017

जब मैं # 2 "NULL मानों को अनुमति देने के लिए बनाए गए कॉलम को बदलता हूं", तो यह मुझे नहीं होने देगा क्योंकि कॉलम मान अभी भी त्रुटि उत्पन्न करते हैं। काफी अटक गया।

— माइक वियर

1

@ माइक वीयर: संभवतः " मुझे नहीं जाने देगा " का अर्थ है कि SQL स्टेटमेंट निष्पादित होने पर एक त्रुटि वापस आती है। की सेटिंग के कारण यह संभव है sql_mode। MySQL के अधिक हाल के संस्करणों की डिफ़ॉल्ट सेटिंग्स sql_modeहैं जो पिछले संस्करणों की तुलना में अधिक सख्त हैं। 8.0 यहाँ संदर्भ: dev.mysql.com/doc/refman/8.0/en/sql-mode.html देखें NO_ZERO_DATE, ALLOW_INVALID_DATE, एट अल। ध्यान दें कि कुछ STRICT मोड में शामिल हैं STRICT_TRANS_TABLES, STRICT_ALL_TABLESऔर अन्य कॉम्बो मोड। प्रतिबंधों को हल करने के लिए, सत्र के लिए अस्थायी रूप से sql_mode को संशोधित करें,

— spencer7593

@ spencer7593 यकीन के लिए। मुझे वह विकल्प अच्छा नहीं लगा। मैंने एक बहुत पुरानी तिथि मान (1970) निर्धारित करने की आपकी सलाह ली और मेरा सिस्टम इसे अनदेखा करेगा। आपके सभी विवरण के लिए धन्यवाद।

— माइक वियर

67

मैंने क्वेरी से पहले ऐसा करके इसे ठीक कर लिया

SET SQL_MODE='ALLOW_INVALID_DATES';

— तारिक खान
स्रोत

यही एकमात्र उत्तर है। ALLOW_INVALID_DATES '; --init-कमांड =' सेट sql_mode = सेट सत्र FOREIGN_KEY_CHECKS = 0 ': के रूप में प्रयुक्त

— Konchog

बहुत बहुत धन्यवाद। बता नहीं सकता कि यह समस्या मेरे लिए क्या दर्द है।

— डाइटर ग्रिबनिट

42

MySQL 5.7 संदर्भ मैनुअल के अनुसार :

MySQL 5.7 में डिफ़ॉल्ट SQL मोड में ये मोड शामिल हैं: ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER और NOENGER। और NO।

चूंकि 0000-00-00 00:00:00वैध DATETIMEमान नहीं है , इसलिए आपका डेटाबेस टूट गया है। यही कारण है कि MySQL 5.7 - जो NO_ZERO_DATEडिफ़ॉल्ट रूप से सक्षम मोड के साथ आता है - जब आप लिखने का ऑपरेशन करने की कोशिश करते हैं तो एक त्रुटि उत्पन्न होती है।

आप अपनी तालिका को सभी अमान्य मानों को किसी अन्य मान्य मान के अनुसार अपडेट कर सकते हैं, जैसे NULL:

UPDATE users SET created = NULL WHERE created < '0000-01-01 00:00:00'

इसके अलावा, इस समस्या से बचने के लिए, मुझे लगता है कि आप हमेशा वर्तमान समय को अपने समान createdक्षेत्रों के लिए डिफ़ॉल्ट मान के रूप में सेट करते हैं, इसलिए वे स्वचालित रूप से भर जाते हैं INSERT। बस करो:

ALTER TABLE users
ALTER created SET DEFAULT CURRENT_TIMESTAMP

— इवान फिल्हो
स्रोत

8

SET sql_mode = 'NO_ZERO_DATE';
UPDATE `news` SET `d_stop`='2038-01-01 00:00:00' WHERE `d_stop`='0000-00-00 00:00:00'

— एंड्रयू मार्च
स्रोत

4

यह उत्तर इस बात की चर्चा से सुधरा होगा कि यह मुद्दा क्यों हल होता है।

— केविन

क्या यह डेटाटाइम संग्रहण को प्रभावित करता है।? या कोई समस्या पैदा करें

— बाइट्स

8

यहाँ मेरा समाधान PhpMyAdmin / Fedora 29 / MySQL 8.0 (उदाहरण के लिए):

set sql_mode='SOMETHING'; काम नहीं करता है , कमांड कॉल सफल है लेकिन कुछ भी नहीं बदला था।

set GLOBAL sql_mode='SOMETHING'; वैश्विक कॉन्फ़िगरेशन स्थायी परिवर्तन बदलें।

set SESSION sql_mode='SOMETHING'; परिवर्तन सत्र कॉन्फ़िगरेशन सत्र चर केवल वर्तमान क्लाइंट को प्रभावित करता है।

https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html

इसलिए मैं यह करता हूं:

SQL_MODE प्राप्त करें: SHOW VARIABLES LIKE 'sql_mode';
परिणाम : ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
परिणाम पर निकालें: NO_ZERO_IN_DATE,NO_ZERO_DATE
नया कॉन्फ़िगरेशन सेट करें: set GLOBAL SQL_MODE='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION'

आप उसी तरीके से अन्य मोड को हटा या जोड़ सकते हैं।

यह फ्रेमवर्क का उपयोग करने और परीक्षण करने के लिए वैश्विक बदलने में सहायक है या प्रश्नों के प्रत्येक फ़ाइल या गुच्छा में sql_mode को निर्दिष्ट किया जाना चाहिए।

यहां पूछे गए एक प्रश्न से अनुकूलित: हाउ-कैन-आई-डिसेबल-मायस्कल-सख्त-मोड

उदाहरण: नवीनतम जूमला 4.0-अल्फा सामग्री स्थापित करें।

संपादित करें: PhpMyadmin में, यदि आपके पास सर्वर का नियंत्रण है, तो आप sql_modeसीधे (और अन्य सभी मापदंडों को) में बदल सकते हैंPlus > Variables > sql_mode

— शिम-साओ
स्रोत

5

आप का प्रकार बदल सकते हैं बनाया से क्षेत्र datetimeके लिए varchar(255)है, तो आप (अपडेट) सभी रिकॉर्ड मूल्य है निर्धारित कर सकते हैं "0000-00-00 00:00:00"करने के लिए NULL।

अब, आप अपने प्रश्नों को त्रुटि के बिना कर सकते हैं। आपके समाप्त होने के बाद, आप अपने द्वारा बनाए गए फ़ील्ड के प्रकार को बदल सकते हैं datetime।

— अब्दुल्ला अजलौनी
स्रोत

4

MySQL को 5.6 से 5.7 तक अपग्रेड करने के बाद भी मुझे यह त्रुटि है

मुझे पता चला कि मेरे लिए सबसे अच्छा समाधान यहां कुछ समाधानों को संयोजित करना और कुछ ऐसा बनाना था जो न्यूनतम इनपुट के साथ काम करता था।

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

...

1।

Db को सुधारने का प्रयास करते समय पहले वास्तविक त्रुटि की जाँच करें:

joomla.jos_menu नोट: पुराने प्रारूप के TIME / TIMESTAMP / DATETIME कॉलम को नए स्वरूप में अपग्रेड कर दिया गया है।

चेतावनी: गलत डाइमटाइम मान: पंक्ति 1 पर कॉलम 'चेक_आउट_टाइम' के लिए '0000-00-00 00:00:00'

त्रुटि: 'check_out_time' के लिए अमान्य डिफ़ॉल्ट मान

स्थिति: ऑपरेशन विफल

यह मुझे बताता है कि तालिका jos_menu में कॉलम check_out_time को सभी खराब तारीखों के साथ-साथ "डिफ़ॉल्ट" परिवर्तन की आवश्यकता है।

...

2।

मैं त्रुटि संदेश में जानकारी के आधार पर SQL क्वेरी चलाता हूं:

UPDATE jos_menu SET checked_out_time = '1970-01-01 08:00:00' WHERE checked_out_time = 0

यदि आपको कोई त्रुटि मिलती है तो आप हमेशा काम करने के लिए नीचे दिए गए क्वेरी का उपयोग कर सकते हैं:

UPDATE jos_menu SET checked_out_time = '1970-01-01 08:00:00' WHERE CAST(checked_out_time AS CHAR(20)) = '0000-00-00 00:00:00'

...

3।

उसके बाद एक बार जब मैं दूसरी SQL क्वेरी चलाता हूं:

ALTER TABLE `jos_menu` CHANGE `checked_out_time` `checked_out_time` DATETIME NULL DEFAULT CURRENT_TIMESTAMP;

या मामले में यह एक तारीख है जिसे NULL होना है

ALTER TABLE `jos_menu` CHANGE `checked_out_time` `checked_out_time` DATETIME NULL DEFAULT NULL;

...

यदि मैं अब मरम्मत डेटाबेस चलाता हूं तो मुझे मिलता है:

joomla.jos_menu ठीक है

...

ठीक काम करता है :)

— डॉन राजा
स्रोत

4

जाँच

SELECT @@sql_mode;

यदि आपको वहां 'ZERO_DATE' सामान दिखाई देता है, तो प्रयास करें

SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'NO_ZERO_DATE',''));   
SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'NO_ZERO_IN_DATE',''));

अपने क्लाइंट के लिए फिर से लॉग आउट करें और वापस जाएं (यह अजीब है) और फिर से प्रयास करें

— commonpike
स्रोत

3

Sql मोड को सख्त न करें

अगर लार्वा का उपयोग करने के लिए कॉन्फ़िगर-> डेटाबेस पर जाएं, तो mysql सेटिंग्स पर जाएं और सख्त मोड को गलत बनाएं

— मिलिंद चौधरी
स्रोत

क्या मैं मायफैडमिन में ऐसा कर सकता हूं?

— डॉन किंग

phpMyAdmin वास्तविक mysql सर्वर का उपयोग करने के लिए सिर्फ एक इंटरफ़ेस है, इससे कोई फर्क नहीं पड़ता कि आप mysql कमांड का उपयोग किस इंटरफ़ेस के साथ कर रहे हैं। इसे बंद करने के लिए इस कमांड (sql_mode = '';) या इस (वैश्विक sql_mode = '' सेट करें) का प्रयास करें।

— मिलिंद चौधरी

1

हाँ, मुझे लगता है कि सख्त मोड को बंद करने के लिए आवश्यक सभी thats sql_mode = (और इसके बाद कुछ भी नहीं) जोड़ रहा है, my.cnf के नीचे से

— डॉन किंग

3

मुझे भी इसी तरह की समस्या थी लेकिन मेरे मामले में कुछ लाइन की वैल्यू NULL थी।

इसलिए पहले मैं टेबल अपडेट करता हूं:

update `my_table`set modified = '1000-01-01 00:00:00' WHERE modified is null

समस्या हल हो गई, कम से कम मेरे मामले में।

— लेनन टोल्फ़ो
स्रोत

2

मैं भी मिला

SQLSTATE [22007]: अमान्य डेटाटाइम प्रारूप: 1292 गलत डेटाटाइम मान: स्तंभ के लिए '0000-00-00 00:00:00'

त्रुटि जानकारी

बदलते कर इसे ठीक 0000-00-00 00:00:00 करने के लिए 1970-01-01 08:00:00

1970-01-01 08:00:00 यूनिक्स टाइमस्टैम्प 0 है

— tekintian
स्रोत

1

समस्या यह है कि ओपी त्रुटि के कारण तारीख को बदल नहीं सकता है। मुझे लगता है कि यह त्रुटि हैNO_ZERO_DATE

— GusDeCooL

2

मुझे https://support.plesk.com/hc/en-us/articles/115000666509-How-to-change-the-SQL-mode-in-MySQL पर समाधान मिला । मेरे पास यह था:

mysql> show variables like 'sql_mode';
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name | Value                                                                                                                                     |
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| sql_mode      | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.01 sec)

NO_ZERO_IN_DATE,NO_ZERO_DATEउपरोक्त परिणामों में ध्यान दें । मैंने ऐसा करके हटा दिया:

mysql> SET sql_mode = 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
Query OK, 0 rows affected, 1 warning (0.00 sec)

तब मेरे पास यह था:

mysql> show variables like 'sql_mode';
+---------------+--------------------------------------------------------------------------------------------------------------+
| Variable_name | Value                                                                                                        |
+---------------+--------------------------------------------------------------------------------------------------------------+
| sql_mode      | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------+--------------------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.01 sec)

ऐसा करने के बाद, मैं ALTER TABLEसफलतापूर्वक उपयोग कर सकता हूं और अपनी तालिकाओं को बदल सकता हूं।

— जयम मोंटोया
स्रोत

1

यही मैंने अपनी समस्या के समाधान के लिए किया। मैंने स्थानीय MySQL 5.7 ubuntu 18.04 में परीक्षण किया ।

set global sql_mode="NO_ENGINE_SUBSTITUTION";

विश्व स्तर पर इस क्वेरी को चलाने से पहले मैंने /etc/mysql/conf.d निर्देशिका में एक cnf फ़ाइल जोड़ी । Cnf फ़ाइल का नाम mysql.cnf और कोड है

[mysqld]
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ALLOW_INVALID_DATES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

फिर मैंने mysql को फिर से शुरू किया

sudo service mysql restart

आशा है कि यह किसी की मदद कर सकता है।

— कल्याण हलदर रज़
स्रोत

यह समाधान तब तक काम कर रहा है जब तक मैं MySQL सर्वर को पुनरारंभ नहीं करता। पुनरारंभ के बाद भी मान NO_ENGINE_SUBSTITUTIONसभी स्तंभों में है, SELECT @@global.sql_mode, @@session.sql_mode, @@sql_mode;लेकिन फिर भी मुझे अमान्य डेटाटाइम के लिए एक त्रुटि मिलती है 0000-00-00 00:00:00जब तक कि मैं पहली क्वेरी फिर से निष्पादित नहीं करता हूं set global sql_mode="NO_ENGINE_SUBSTITUTION";कोई विचार?

— स्मामत्ती

मेरे मामले में समाधान NO_ZERO_IN_DATE,NO_ZERO_DATEmy.ini लाइन के आपके संस्करण को हटाने को परिभाषित करना था sql_mode।

— स्मामत्ती

1

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

दागी कॉलम की आईडी चुनें।

select id from table where BadColumn='0000-00-00 00:00:00'
आईडी को कॉमा-सीमांकित स्ट्रिंग में इकट्ठा करें। उदाहरण: 1, 22, 33। मैंने इसके लिए एक बाहरी आवरण का उपयोग किया (एक पर्ल स्क्रिप्ट) जो जल्दी से उन सभी को बाहर करने के लिए थूक देता है।
मान्य कॉलम (2038 के माध्यम से 1971) के साथ पुराने कॉलम को अपडेट करने के लिए अपनी सूची की सूची का उपयोग करें।

update table set BadColumn='2000-01-01 00:00:00' where id in (1, 22, 33)

— felwithe
स्रोत

1

मेरा समाधान

SET sql_mode='';
UPDATE tnx_k2_items
SET created_by = 790
, modified = '0000-00-00 00:00:00'
, modified_by = 0

— VietPublic
स्रोत

1

के बजाय

UPDATE your_table SET your_column = new_valid_value where your_column = '0000-00-00 00:00:00';

उपयोग

UPDATE your_table SET your_column = new_valid_value where your_column = 0;

— R2D3
स्रोत

0

यदि आप मैन्युअल रूप से डेटा दर्ज कर रहे हैं, तो आप TIMESTAMP (6) .000000 पर मान और शून्य हटाने पर विचार कर सकते हैं ताकि यह TIMESTAMP हो जाए। कि मेरे साथ ठीक काम किया।

— इसहाक
स्रोत