Erreur de base de données mise à jour de 15.0.0 à 16.0.3

Maintenir mon Dolibarr
, ,
1
Version du serveur de base de données 5.5.5-10.1.44-MariaDB-0+deb9u1
Jeu de caractères du client utf8
Jeu de caractère de tri du client utf8_general_ci

Bonjour à tous,

Actuellement je suis en version 15.0.0 je je veux me mettre à jour en version 16.0.3.

J’ai suivi la procédure :

Procédure de mise à jour:
Étape 1: Télécharger le package (par exemple depuis le site web officiel Downloads, Dolibarr ERP CRM packages and addons)

Étape 2: Décompressez les fichiers packagés dans le répertoire de votre serveur Dolibarr : /var/www/mon_dolibar/

Étape 3: Effacer le fichier dans /home/documents/_conseil_home/documents/install.lock s’il existe afin d’autoriser l’outil de mise à jour.

Étape 4: Aller à la page de mise à jour de la structure et des données de la base : /htdocs/install/.
Suivez les instructions de l’installation

Étape 5: Replacer un fichier /home/documents/install.lock, en ne donnant que les droits
de lecture sur ce fichier, afin d’interdire à nouveau les mises à jour.

Suite à l’étape 4, j’ai un message d’erreur.

Choix du script de migration 15.0.0-16.0.0.sql

Erreur DB_ERROR_1071: ALTER TABLE llx_facture_fourn_rec ADD UNIQUE INDEX uk_facture_fourn_rec_ref (titre, entity);
Specified key was too long; max key length is 767 bytes

|Erreur DB_ERROR_1071: ALTER TABLE llx_asset_depreciation ADD UNIQUE uk_asset_depreciation_fk_asset (fk_asset, depreciation_mode, ref);
Specified key was too long; max key length is 767 bytes|

J’ai cherché sur le forum

Ils disent si notre pas de donnée est en utf8mb4_general_ci il faut la convertir en utf8_general_ci.

Ma base de donnée, elle est en utf8_general_ci comme annoncé en debut.

Pouvez-vous m’aider ?

Alain

2

Est-ce possible d’exécuter ces requêtes SQL et de donner les réponses ?

show global variables like 'innodb_default_row_format';
show global variables like 'innodb_file_format';
show global variables like 'innodb_file_per_table';
show global variables like 'innodb_large_prefix';
3

Bonjour,

Voici les résultats :

show global variables like 'innodb_default_row_format';

Variable_name |Value |
-------------------------±------+
innodb_default_row_format|compact|

show global variables like 'innodb_file_format';

Variable_name |Value |
------------------±-------+
innodb_file_format|Antelope|

show global variables like 'innodb_file_per_table';

Variable_name |Value|
---------------------±----+
innodb_file_per_table|ON |

show global variables like 'innodb_large_prefix';

Variable_name |Value|
-------------------±----+
innodb_large_prefix|OFF |

Et j’ai revérifié la base de donnée est bien en uft8_general_ci

encodage par defaut : utf8
collation par defaut : uft8_general_ci

Avez-vous une solution pour y remédier ?
Merci

Alain

4

La solution « connue » consiste à remettre au format utf8. Il reste certainement des tables ou des colonnes en utf8mb4_general_ci. Il faut éventuellement chercher là où c’est en utf8mb4_general_ci mais la conversion risque de casser des caractères donc il faut bien sauvegarder avant, exporter,… Repasser en utf8_general_ci peut être la meilleure solution sur Debian 9.

Mais l’autre solution à l’avenir serait d’avoir (je n’ai pas testé mais c’est ce que je trouve en cherchant ) :
innodb_large_prefix à ON
innodb_file_format à Barracuda
innodb_default_row_format à dynamic

Toutes ces manipulations doivent se faire avec une énorme précaution, sauvegarder, être sûr et certain de la bonne sauvegarde.