Ceci fait suite à cette question MYSQL format DATETIME incorrect
Comment se débarrasser de STRICT_TRANS_TABLES une fois pour toutes?
mysql --help
rapporte les configs suivants:
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /usr/local/etc/my.cnf ~/.my.cnf
$ ls /etc/my.cnf /etc/mysql/my.cnf /usr/local/etc/my.cnf ~/.my.cnf
ls: /Users/pain/.my.cnf: No such file or directory
ls: /etc/mysql/my.cnf: No such file or directory
ls: /usr/local/etc/my.cnf: No such file or directory
/etc/my.cnf
$ cat /etc/my.cnf
[mysqld]
sql_mode=NO_ENGINE_SUBSTITUTION
Mais cela n'aide pas. J'ai un code hérité et chaque fois que je redémarre l'ordinateur, je dois lancer mysql et changer sql_mode.
Mettre à jour
J'ai donc abandonné MySQL installé sur Homebrew et je l'ai téléchargé à partir de mysql.com. Mais cela n'a pas aidé non plus. En suivant les réponses ici: Comment réparer `variable inconnue 'sql-mode = ANSI'`? J'ai essayé différentes variantes de /etc/my.cnf
: [mysql]
, [mysqld]
, sql_mode
, sql-mode
- rien n'y fait.
Donc au final, j’ai enlevé le serveur MySQL que j’ai reçu de mysql.com, je l’ai réinstallé via Homebrew et je devais
/usr/local/Cellar/mysql/5.6.xx/my.cnf
Où je pourrais commenter le fichu STRICT_TRANS_TABLES
.
Cependant, cela n’explique pas pourquoi la configuration par défaut remplace celle de /etc/my.cnf
, mais j’y ai passé trop de temps déjà. Et au fait, je ne sais toujours pas quoi faire de la distribution fournie par mysql.com.
Ce problème m'a aussi bouleversé pendant un moment. Jusqu'à présent, aucune des réponses apportées ne résout le problème initial, mais je pense que la mienne le fait. Je le posterai au cas où cela aiderait quelqu'un d'autre.
J'ai MySQL (de mysql.com) Community Edition 5.7.10 installé sur OS X 10.10.3
Finalement, j'ai créé un /etc/mysql/my.cnf
avec le contenu suivant: -
[mysqld]
sql_mode=NO_ENGINE_SUBSTITUTION
Après avoir redémarré le serveur, un SHOW VARIABLES LIKE 'sql_mode';
m'a donné: -
+---------------+------------------------+
| Variable_name | Value |
+---------------+------------------------+
| sql_mode | NO_ENGINE_SUBSTITUTION |
+---------------+------------------------+
1 row in set (0.00 sec)
Enfin, pas de mode strict!
Sur Centos 6.5, j’ai dû éditer /usr/my.cnf
Et le définir (même si /etc/my.cnf
existait et que les liaisons y étaient définies
[mysqld]
sql_mode=NO_ENGINE_SUBSTITUTION
le paquet venait de:
mysql-community-client.x86_64 5.6.16-1.el6 @mysql56-community
Selon MySQL Strict Mode sous OS X , le paramètre problématique est en fait sur /usr/local/mysql/my.cnf
et peut être commenté pour arrêter ce problème.
Maintenant, vous ne pouvez pas définir sql_mode sur une chaîne vide, la requête est:
SET @@GLOBAL.sql_mode="STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
MySQL 5.7.16
J'ai essayé toutes les réponses que je pouvais trouver sur ce problème en utilisant MySQL 5.7 sur Mac OS 10.12 et, finalement, le mode strict a été désactivé, pas à cause de l'emplacement de my.cnf, qui peut vraisemblablement se trouver à n'importe quel endroit que MySQL dit vérifier, grâce à un problème d'autorisations UNIX.
J'ai utilisé MySQL Workbench 6.2.3.12313 pour créer initialement my.cnf. Cela posait deux problèmes: premièrement, il définissait l'option sur "sql-mode" au lieu de "sql_mode" et rendait le fichier (situé dans/etc) lisible et inscriptible uniquement pour root. MySQL ne fonctionne pas en tant que root lorsque vous l'installez correctement, à partir du paquet binaire situé sur le site Web de MySQL. Il s'exécute en tant que _mysql. Ainsi, l’utilisateur _mysql doit pouvoir lire /etc/my.cnf, où que vous soyez. Pour que cela fonctionne, vous devez exécuter:
Sudo chmod o+r /etc/my.cnf
et pour faire bonne mesure, vous pouvez aussi lancer:
Sudo chmod g+r /etc/my.cnf
Ensuite, assurez-vous de redémarrer MySQL. (J'ai constaté que cela fonctionnait mieux avec le panneau des préférences système de MySQL sous Mac OS; utiliser la ligne de commande est un peu compliqué et les fonctionnalités de MySQL Workbench ne fonctionnent tout simplement pas.) Tant que vous avez défini un paramètre sql_mode dans n'implique pas le mode strict, le mode strict doit être désactivé.
Sur Mac OS X, El Capitan i a créé un fichier .my.cnf dans le répertoire personnel de l'utilisateur et a défini les paramètres de mysql sous [mysqld]
, puis a redémarré mysql. A bien fonctionné!
Vous devez rechercher sql-mode et sql_mode, s'il existe un paramètre existant. http://it.i88.ca/2014/03/how-to-get-rid-of-strict-sql-mode-in.html