visible dans le fichier conf/conf.php
Cela viendrait du fait que c’est le jeu de caractères par défaut des bases MySQL
cela m’a occasionné parfois des erreurs en important des données en UTF8
→ est-ce que vous pensez qu’on peut garder ces encodages au lieu de utf8 ?
→ ou faut-il repasser le fichier conf.php en utf8 ?
merci pour ce fil, j’ai appliqué le script de réparation /install/repair.php?force_utf8_on_tables=confirmed
Il s’est bien passé, cependant le fichier conf.php n’a pas changé, c’est toujours en latin1_swedish_ci , est-ce que c’est gênant ?
cordialement
Pour MariaDB cela varie en fonction de la distribution linux. Normalement c’est latin1latin1_swedish_ci par défaut, mais sur Debian par exemple ça va être utf8mb4 et utf8mb4_general_ci
C’est parfois presque aussi joyeux à gérer que les timezones
@MatthieuM le mieux c’est quand même de le changer pour que se soit cohérent.
Le problème actuellement c’est que pour créer de nouvelles tables (première installation, ou activation de module) Dolibarr n’utilise pas les informations du fichier conf.php, mais par contre pour enregistrer les données dedans oui.
Cela reste des opérations que les hébergeurs Dolibarr font mécaniquement/automatisés sur leur scripts d’installation (normalement).
OVH décide pour vous une mauvaise valeur par défaut.
En fait il faut demander à votre moteur de base de donnée quelle est la collation et le character_set d’une connexion par défaut et mettre ça dans le fichier conf.php de Dolibarr ou le modifier (par exemple avec phpmyadmin ou en SQL) pour que cela soit cohérent de partout.
Pour connaître ces informations par defaut en SQL
SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';
Suite à cette manipulation, mes sauvegardes antérieures au changement de charset ne sont plus importables par l’outil phpmyadmin ( erreur d’import, même en désactivant la vérification des clés étrangères )
J’ai donc édité le fichier .sql de la sauvegarde antérieure au changement de charset en remplaçant toutes les occurrences de CHARSET=latin1; par CHARSET=utf8; avec un éditeur de texte
Puis dans phpmyadmin j’ai dû supprimer toutes les tables à la main car certaines tables avaient été importées en latin1 dans la tentative échouée
Il faut indiquer utf8mb4_unicode_ci à la place de utf8mb4_general_ci pour dolibarr_main_db_collation et ensuite s’arranger pour que ce soit la même chose dans la base de données.
Merci pour l’aide. J’ai tenté et voici le message que je reçois :
Erreur de requête: #1832 - Cannot change column ‹ fk_pcg_version ›: used in a foreign key constraint ‹ omcoi_doli873/fk_accounting_account_fk_pcg_version ›
Quand je tente de modifié avec la requête SQL suivante :
ALTER TABLE llxgj_accounting_account CHANGE fk_pcg_versionfk_pcg_version VARCHAR(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL;
Le repair.php de Dolibarr v20.0.1+ prend en charge cette erreur de clé étrangère qui empeche l’alignement complet en utf8 de tous les champs de toutes les tables.
A lancer donc par
/install/repair.php?force_utf8_on_tables=confirmed
Ou mieux pour de l’utf8mb4 qui saura gérer les smileys :
/install/repair.php?force_utf8mb4_on_tables=confirmed
Après avoir mis à jour en v20.0.1
Juste une question qui me chagrine et qui est encore de mise sur la branche develop aujourd’hui.
Je crée un base de données via MariaDB, qui par défaut me fait en UTF8mb4 et UTF8mb4_unicode_ci, J’ouvre un dolibarr develop tout frais, je fais l’installation et dans mon fichier conf.php autogénéré je me retrouve avec :
Pourquoi cela ?
Si je veux utiliser les émojis dans mes emails, la table llx_actioncomm crash en me disant que j’ai des mauvais caractères dans le champ note.
Si je modifie à la main le fichier conf.php pour refléter l’utf8mb4 ça marche.
Merci d’avance