Esta crónica fue aprobado por nuestros expertos para que tengas la seguridad de la exactitud de nuestro tutorial.
Solución:
El error se debe al modo sql, que puede ser un modo estricto según la última documentación de MYSQL 5.7
MySQL Documentación 5.7 dice:
El modo estricto afecta si el servidor permite ‘0000-00-00’ como una fecha válida: si el modo estricto no está habilitado, se permite ‘0000-00-00’ y las inserciones no producen ninguna advertencia. Si el modo estricto está habilitado, ‘0000-00-00’ no está permitido y las inserciones producen un error, a menos que también se proporcione IGNORE. Para INSERT IGNORE y UPDATE IGNORE, se permite ‘0000-00-00’ y las inserciones generan una advertencia.
Para comprobar el modo MYSQL
SELECT @@GLOBAL.sql_mode global, @@SESSION.sql_mode session
Deshabilitando el modo STRICT_TRANS_TABLES
Sin embargo, para permitir el formato 0000-00-00 00:00:00debe deshabilitar el modo STRICT_TRANS_TABLES en el archivo de configuración mysql o por comando
por comando
SET sql_mode = '';
o
SET GLOBAL sql_mode = '';
Usando la palabra clave GLOBAL requiere súper previligios y afecta las operaciones todos los clientes se conectan a partir de ese momento
si lo anterior no funciona, vaya a /etc/mysql/my.cnf (según ubuntu) y comentar STRICT_TRANS_TABLES
Además, si desea configurar permanentemente el modo sql al iniciar el servidor, incluya SET sql_mode='' en my.cnf en Linux o MacOS. Para Windows esto tiene que hacerse en my.ini expediente.
Nota
Sin embargo, el modo estricto no está habilitado de forma predeterminada en MYSQL 5.6. Por lo tanto, no produce el error según la documentación de MYSQL 6 que dice
MySQL le permite almacenar un valor “cero” de ‘0000-00-00’ como una “fecha ficticia”. En algunos casos, esto es más conveniente que usar valores NULL y usa menos datos y espacio de índice. Para deshabilitar ‘0000-00-00’, habilite el modo SQL NO_ZERO_DATE.
ACTUALIZAR
Con respecto al asunto del error como dijo @Dylan-Su:
No creo que este sea el error, ya que la forma en que MYSQL ha evolucionado con el tiempo debido a que algunas cosas cambian en función de la mejora adicional del producto.
Sin embargo, tengo otro informe de error relacionado con el NOW() función
El campo de fecha y hora no acepta el valor predeterminado AHORA()
Otra nota útil [see Automatic Initialization and Updating for TIMESTAMP and DATETIME]
A partir de MySQL 5.6.5, las columnas TIMESTAMP y DATETIME se pueden inicializar y actualizar automáticamente a la fecha y hora actuales (es decir, la marca de tiempo actual). Antes de 5.6.5, esto es true solo para TIMESTAMP, y como máximo una columna TIMESTAMP por tabla. Las siguientes notas describen primero la inicialización y actualización automáticas para MySQL 5.6.5 y posteriores, luego las diferencias para las versiones anteriores a 5.6.5.
Actualización sobre NO_ZERO_DATE
A partir de MySQL a partir de 5.7.4, este modo está en desuso. Para la versión anterior, debe comentar la línea respectiva en el archivo de configuración. Consulte la documentación de MySQL 5.7 en NO_ZERO_DATE
Tuve este error con WAMP 3.0.6 con MySql 5.7.14.
Solución:
cambie la línea 70 (si su archivo ini está intacto) en c:wampbinmysqlmysql5.7.14my.ini archivo de
sql-mode= "STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ZERO_DATE,NO_ZERO_IN_DATE,NO_AUTO_CREATE_USER"
para
sql-mode="ERROR_FOR_DIVISION_BY_ZERO,NO_ZERO_DATE,NO_ZERO_IN_DATE,NO_AUTO_CREATE_USER"
y reiniciar todos los servicios.
Esto deshabilitará el modo estricto. Según la documentación, “modo estricto” significa un modo con uno o ambos STRICT_TRANS_TABLES o STRICT_ALL_TABLES activado. La documentación dice:
“El modo SQL predeterminado en MySQL 5.7 incluye estos modos: ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER y NO_ENGINE_SUBSTITUTION”.
Me metí en una situación en la que los datos eran mixed entre NULL y 0000-00-00 para un campo de fecha. Pero no sabía cómo actualizar el ‘0000-00-00’ a NULL, porque
update my_table set my_date_field=NULL where my_date_field='0000-00-00'
ya no está permitido. Mi solución fue bastante simple:
update my_table set my_date_field=NULL where my_date_field<'1000-01-01'
porque todo lo incorrecto my_date_field los valores (ya sean fechas correctas o no) eran anteriores a esta fecha.
Calificaciones y comentarios
Si te ha resultado de provecho nuestro post, agradeceríamos que lo compartas con más desarrolladores así nos ayudas a dar difusión a este contenido.