ERROR 1292 (22007): Incorrect datetime value: ‘1970-00-00 08:00:00’ for column ‘GMT_CLEANUP’ at row 1;
Find the error message:
$perror 1292
错误：1292 SQLSTATE: 22007 (ER_TRUNCATED_WRONG_VALUE)
Then think of would be the original table in mysql alter table add column runs temporary copy, make changes on the copy, and then delete the original table, and then rename the new table. So the reason being given is ddl copy in the course of the original table, find the data in the table GMT_CLEANUP '0000-00-0000: 00: 00' in the process copy table, mysql think that the data is not legitimate data:
The first question : why 0000-00-00 00:00:00 mysql think is not correct?
The second question : 0000-00-00 00:00:00 how he has been inserted into the database, the application of such demand it?
For the first question, still need to return to the mysql definition of date and time, description on the official document will allow MySQL '0000-00-00' as a "dummy date" (if you do not use NO_ZERO_DATE SQL mode). In some cases it is more convenient than using a NULL value (and the data and index smaller footprint). So then, is to look at the parameters of the sql_mode;
root@DB06:40:48>show variables like ‘sql_mode’;
| sql_mode | STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL |
1 row in set (0.00 sec)
参数中含有STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,
In strict mode, do not '0000-00-00' as a legitimate date. You can still insert zero dates with the IGNORE option. In non-strict mode, you can accept that date, but will generate a warning.
NO_ZERO_IN_DATE
In strict mode, do not accept the month or day part of the date zero. If you use the IGNORE option, we insert date '0000-00-00'. In non-strict mode, you can accept that date, but will generate a warning.
Problem can be solved , change sql_mode: no_zero_in_date removed and the no_zero_date:
SET Global the sql_mode
= 'NO_AUTO_CREATE_USER';
Query OK, 0 rows affected (0.00 sec)
root@DB 07:07:01>show variables like ‘%sql_mode%’;
| sql_mode | NO_AUTO_CREATE_USER |
1 row in set (0.00 sec)
That is, remove all restrictions sql_mode in, you can insert a null value of the time, the problem is solved! ! !
root@DB 07:07:10>exit
Bye
Why this happens is not the right parameter settings, see the library sql_mode other parameters are not set, except this library sql_mode set, it appears that the need for a detailed understanding of the sql_mode:
Simply put sql_mode which is set sql syntax, and what kind of data validation checks should mysql support. This makes it easier to use MySQL in different environments and in combination with other database server MySQL. By using SET [SESSION | GLOBAL] statement sets the variable sql_mode sql_mode = 'modes' to change the SQL mode. SUPER need to have permissions set GLOBAL variable, and can affect the operation and since then all client connections. Set SESSION variable affects only the current client. Any client can change its own session sql_mode value at any time.
Sql_mode current database are:
STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER
These values, which is to be set up sql_mode: TRADITIONAL mode, so only remove NO_ZERO_IN_DATE, NO_ZERO_DATE is not enough, but also to remove TRADITIONAL;
Be sure to remember to change to take effect after re-entering the database! ! ! !
To exit and re-login:
show variables like ‘%sql_mode%’;
Has seen can modify the structure of the table, and now mysql allow the ddl.
For the second question: Why would the insertion 0000-00-00 00:00:00?
. Date strict mode allows the use of "zero" portion, for example, '2004-04-00' or "zero" date. To ban, should be based on strict mode enabled NO_ZERO_IN_DATE and NO_ZERO_DATE SQL mode.
. Each type has a value of time effective range and a "zero" value of "zero" when the value of the specified unlawful MySQL can not be represented.
. Invalid DATETIME, DATE or TIMESTAMP value is converted to "zero" value of the corresponding type ( '0000-00-00 00:00:00', '0000-00-00' or 00 trillion).
From the above it can be seen sql_mode in strict mode (enabled or STRICT_TRANS_TABLES STRICT_ALL_TABLES mode) is inserted: 0000-00-00 00:00:00 ', but later also started TRADITIONAL, TRADITIONAL there NO_ZERO_IN_DATE and NO_ZERO_DATE mode, so early 0000-00-00 00:00:00 insert the data, followed by a change of sql_mode, leading to the insertion of the inserted before the data becomes invalid, thus giving rise to the overall total above problems.