valeur par défaut non valide (mysql 5.7) pour le champ d'horodatage


10

EDIT: lors de la mise à jour d'une base de données existante à partir de mysql 5.6 et de l'exécution:

UPDATE phppos_register_log SET shift_end = '2015-01-01 00:00:00' WHERE shift_end = '0000-00-00 00:00:00';

Cela produit:

#1292 - Incorrect datetime value: '0000-00-00 00:00:00' for column 'shift_end' at row 1
#1067 - Invalid default value for 'shift_start' 

Cela a fonctionné dans mysql <= 5.7. Je n'ai trouvé aucune documentation à ce sujet ... Quel est le problème avec cela?

CREATE TABLE `phppos_register_log` (
      `register_log_id` int(10) NOT NULL AUTO_INCREMENT,
      `employee_id_open` int(10) NOT NULL,
      `employee_id_close` int(11) DEFAULT NULL,
      `register_id` int(11) DEFAULT NULL,
      `shift_start` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
      `shift_end` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
      `open_amount` decimal(23,10) NOT NULL,
      `close_amount` decimal(23,10) NOT NULL,
      `cash_sales_amount` decimal(23,10) NOT NULL,
      `total_cash_additions` decimal(23,10) NOT NULL DEFAULT '0.0000000000',
      `total_cash_subtractions` decimal(23,10) NOT NULL DEFAULT '0.0000000000',
      `notes` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
      `deleted` int(1) NOT NULL DEFAULT '0',
      PRIMARY KEY (`register_log_id`),
      KEY `phppos_register_log_ibfk_1` (`employee_id_open`),
      KEY `phppos_register_log_ibfk_2` (`register_id`),
      KEY `phppos_register_log_ibfk_3` (`employee_id_close`),
      CONSTRAINT `phppos_register_log_ibfk_1` FOREIGN KEY (`employee_id_open`) REFERENCES `phppos_employees` (`person_id`),
      CONSTRAINT `phppos_register_log_ibfk_2` FOREIGN KEY (`register_id`) REFERENCES `phppos_registers` (`register_id`),
      CONSTRAINT `phppos_register_log_ibfk_3` FOREIGN KEY (`employee_id_close`) REFERENCES `phppos_employees` (`person_id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

1
Ce problème est documenté ... mais d'abord, quelle version de MySQL 5.7 utilisez-vous (particulièrement pertinente, car 5.7 n'est pas encore GA à partir de maintenant)? et il y avait un changement mal conçu introduit en 5.7.4 qui a été annulé en 5.7.8, qui expliquerait cela. Veuillez confirmer votre version.
Michael - sqlbot

mysql-5.7.8-rc-osx10.9-x86_64.dmg
Chris Muench

J'ai posté une modification avec un autre problème. Cela semble être un vrai problème avec mysql 5.7.8
Chris Muench

2
Un examen plus approfondi des notes de version 5.7.8 suggère qu'une modification a été annulée, mais que vous devrez peut-être la supprimer NO_ZERO_DATE, qui fait désormais partie de la configuration par défaut. Pouvez-vous confirmer? Je vous en prie SELECT @@SQL_MODE;.
Michael - sqlbot

Oui, j'ai changé de mode et cela a fonctionné. J'ai trouvé beaucoup de choses que mysql 5.7 a ajouté qui ont causé un problème, j'ai donc réglé le mode sur ""; cela semble être une mise à jour assez importante avec beaucoup de changements.
Chris Muench

Réponses:


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.