Besoin d'aide pour gros nettoyage de printemps

Bonjour,

Voici en quelques mots la situation : nous avons démarré avec un doli 3.6.2 sur une debian, ce jusqu’en 4.0.4 puis le doli a été migré sur dolicloud et mis à jour jusqu’en 5.0.3 ; le tout avec ajout de modules du dolistore.
Sur la debian initiale, on a donc fait 3.6.2 => 4.0.4
L’archi dolicloud étant au départ plus ancienne, l’historique de la base est aujourd’hui 3.2.3 => 5.0.3
J’ai voulu remettre doli sur une debian parce que, depuis le passage sur dolicloud, je rencontrais plusieurs erreurs de type

Illegal mix of collations (utf8_unicode_ci,IMPLICIT) and (utf8_general_ci,IMPLICIT) for operation '='
Je rencontre actuellement cette erreur quand je veux accéder à l’ensemble des mouvements de stock ainsi que, au sein du module compta avancée, quand je cherche à lier des lignes de note de frais.
J’ai aussi un comportement bizarre sur les PR : www.dolibarr.fr/forum/t/tiers-contact-proposition-aleatoire/24981/1

Le contenu de la base ayant évidemment bien évolué depuis la 4.0.4 qui était stable, je ne peux pas repartir de cette version pour upgrader en 5.0.3 sur ma debian actuelle.
Néanmoins, je constate parfois de grandes différences dans la syntaxe de création de certaines tables entre ma base actuelle (qui a fait 3.2.3 => 5.0.3) versus une 5.0.3 neuve ; des différences notamment sur l’encodage et le collation. J’imagine que c’est de là que proviennent toutes ces petites et moins petits désagréments.

La question est aussi simple que je sens que la réponse va être complexe : comment faire pour repartir sur une structure et une syntaxe de base propre, en 5.0.3, tout en conservant le contenu utile des tables ?
Installer un doli neuf, j’en fait mon affaire ; le reconfigurer à la main entièrement aussi, même si cela prendra un peu de temps sur le module de compta. Je n’utilise actuellement aucun module custom et suis en niveau ‹ 0 › (stable only) pour la conf de dolibarr.
Par contre, il est évident que je ne vais pas recréer à la main tous les documents commerciaux et comptables. J’imagine donc qu’il faut passer des exports / imports bien précis, préalablement épurés des choses inutiles à date actuelle (des restes de modules custom par ex.)

Je peux comprendre qu’il s’agit d’un cas particulier, qui nécessite un traitement dédié donc que les sociétés de service autour de doli n’hésitent pas à me contacter par PM.

Merci !

bonjour

pas sur que ca marche mais c est ce que je tenterais

creer une installation propre avec la meme version qui pose probleme
exporter seulement les données de l installation qui pose probleme et l importer dans la nouvelle installation

Merci pour la réponse mais c’est là qu’est le hic : quels paramètres adopter pour exporter proprement toutes les données ?

À re-réfléchir, je me dis que l’on peut voir le problème différemment, tout en conservant mon hypothèse de base qui est que les problèmes viendraient de tables comportant des encodages et collations différents.

La plupart de mes tables sont déclarées avec un encodage UTF-8 Unicode et collation utf8_general_ci.
Quelques tables sont déclarées avec un encodage UTF-8 Unicode et collation utf8_unicode_ci.
Enfin, quelques tables sont déclarées avec un encodage cp1252 West European (latin1) et collation latin1_swedish_ci.

Prenons l’hypothèse la plus négative où certaines tables ne soient pas réellement encodées avec le charset déclaré : il me faudrait donc convertir (et pas seulement changer l’encodage) toutes les tables vers du UTF-8 Unicode et collation utf8_general_ci.
D’après ce que j’ai lu, la bonne méthode est de convertir la table en binaire puis de la ré-encoder en UTF-8 Unicode et collation utf8_general_ci mais je n’ai jamais fait de SQL et je ne voudrais pas tout saccager donc quelqu’un pourrait-il me donner la ou les bonne(s) requête(s) à appliquer ?

Bonjour,

Vous pouvez changer/convertir la collation de tables (attention il ne doit pas y avoir de colonne de type enum qui n’existe pas en standard avec Dolibarr, mais qui peuvent être crée par certain module externe (comme customFields).

La bonne collation est celle déclaré dans le fichier htdocs/conf/conf.php de dolibarr

Dans le cas en effet ou des tables, pour des raisons historiques, ont des encodages différents, il est possible de se remettre en situation normal (en général le utf8_unicode_ci) en lançant les commandes suivantes (à faire uniquement sur les champs varchar qui posent problème):

ALTER TABLE nomtable MODIFY nomchamp VARCHAR(20) CHARACTER SET utf8;
ALTER TABLE nomtable MODIFY nomchamp VARCHAR(20) COLLATE utf8_unicode_ci;

La commande
show full columns from nomtable
permet d’avoir des informations sur l’encodage des champs d’une table.

Merci à vous deux, je pense avoir résolu mes petits soucis, en particulier grâce au topic SOF de FHenri.