Latin1_swedish_ci / utf8_general_c

bonjour à tous

sur mes installations sur hébergement OVH les bases de données MySQL sont systématiquement initialisées avec les paramètres

$dolibarr_main_db_character_set='latin1';
$dolibarr_main_db_collation='latin1_swedish_ci';

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 ?

Bonjour,

voir ce message : Illegal mix of collations (utf8_unicode_ci,IMPLICI - #3 par ksar

Il y a un script dans dolibarr qui permet de corriger cela

@+

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

C’est le cas pour MySQL 5.7.

Pour MySQL 8 c’est utf8mb4 et utf8mb4_0900_ai_ci

Pour MariaDB cela varie en fonction de la distribution linux. Normalement c’est latin1 latin1_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 :sweat_smile:

1 « J'aime »

@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%';

merci pour les réponses, je ne pensais pas que ça m’emmènerait si loin
quand je fais ces requêtes SQL j’ai le résultat suivant :

avant script /install/repair.php?force_utf8_on_tables=confirmed ( par défaut chez OVH donc )

|character_set_client|      utf8mb4|
|character_set_connection|  utf8mb4|
|character_set_database|    latin1|
|character_set_filesystem|  binary|
|character_set_results|     utf8mb4|
|character_set_server|      latin1|
|character_set_system|      utf8|
|character_sets_dir|       /usr/share/mysql/charsets/|

collation_connection        utf8mb4_unicode_ci
collation_database          latin1_swedish_ci
collation_server            latin1_swedish_ci

et après :

|character_set_client|      utf8mb4|
|character_set_connection|  utf8mb4|
|character_set_database|    utf8|       <*****
|character_set_filesystem|  binary|
|character_set_results|     utf8mb4|
|character_set_server|      latin1|
|character_set_system|      utf8|
|character_sets_dir|       /usr/share/mysql/charsets/|

collation_connection        utf8mb4_unicode_ci
collation_database          utf8_general_ci     <*****
collation_server            latin1_swedish_ci

est-ce que du coup je change le fichier conf.php en

$dolibarr_main_db_character_set='utf8';
$dolibarr_main_db_collation='utf8_general_ci';

?

merci !

Pour info :

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

Ensuite l’import fonctionne à nouveau


J’ai également édité le fichier conf.php

$dolibarr_main_db_character_set='utf8';
$dolibarr_main_db_collation='utf8_general_ci';

Bonsoir,
je ne parviens pas à résoudre mon souci de :

Illegal mix of collations (utf8mb3_unicode_ci,IMPLICIT) and (utf8mb3_general_ci,IMPLICIT) for operation ‹ = ›

J’ai bien executé le script proposé plus haut. J’ai vérifié que le conf.php contienne bien :

$dolibarr_main_db_character_set=‹ utf8 ›;
$dolibarr_main_db_collation=‹ utf8_general_ci ›;

Infos Dolibarr :

Infos PHP

Paramètre Valeur
Version 8.1.29
default_charset UTF-8 UTF-8

Infos base de données
Base de données
Version MySQL or MariaDB 10.6.19-MariaDB

Encodage base pour stockage données latin1
Encodage base pour tri des données latin1_swedish_ci

J’ai manuellement cliqué sur chaque BDD, via la liste Dolibarr pour toutes les passer en UTF8mb4 (elles étaient en UTF8mb3).

Merci de m’aider car j’ai besoin de lier mes factures avant le 10 octobre 2024 … :cold_face:

Mon Général !

unicode != general

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.

Bonjour,

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_version fk_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

Merci, cela à bien fonctionné !!

Merci @eldy pour ces réponses.

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 :

$dolibarr_main_db_character_set='utf8';
$dolibarr_main_db_collation='utf8_unicode_ci';

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