Bonjour,
Il m’est impossible de migrer de 3.1.0 à 3.2.2 sur mon serveur Debian. J’ai une seule erreur, mais elle met la migration KO:
Ayant lu quelques topics similaires, j’ai essayé le script repair.php qui se déroule bien mais je continue d’avoir cet unique message d’erreur bloquant lorsque je retente une migration. Depuis plusieurs années que j’utilise Dolibarr, c’est la première fois qu’une migration à une version supérieure foire avec autant de constance… 
Je me réponds: j’ai désactivé temporairement pour la migration le contrôle des clés étrangères, via
SET foreign_key_checks = 0et la migration est passée, mais cette manip est-elle sans dommage caché ? Ce contrôle ne posait pas de souci jusqu’ici…
ne pas oublier le SET foreign_key_checks = 1 une fois terminé pour réactiver le contrôle des clefs étrangères.
Sinon ça n’impacte en rien
Oui, c’est pour cela que j’ai indiqué « temporairement » 
Merci pour la confirmation que la suppression de l’index bloquant n’a pas d’impact sur l’appli.
Eh bien non ce n’est pas résolu: maintenant j’ai un joli message d’erreur en accédant à l’onglet « catégorie » d’un tiers client/prospect: 
Bilan: retour à la 3.11, qui marche.
Pouvez vous vérifier si la table llx_categorie_societe est bien présente dans votre version. Votre base est bien nommée dolibarrprod ?
La requete est bonne. Peut être un soucis de contrainte entre llx_societe et llx_categorie_societe.
La base était bien dolibarrprod. J’ai refait une tentative cette fois non pas avec une copie de la base de prod mais avec une base de test, pour une migration 3.1.1 vers 3.2.0 et cela coince au même endroit.
Cette table llx_categorie_societe est bien détruite au cours de la migration donc pourquoi générer par la suite ces requêtes sur une table abandonnée car les catégorie créées en 3.1.1 le sont en fait dans la table llx_categorie ?
Il y a aussi quelques warnings concernant la cohérence de la structure.
2013-01-21 09:07:42 WARN ::1 nologin upgrade DoliDBMysql::query SQL error: ALTER TABLE llx_product_fournisseur_price ADD CONSTRAINT fk_product_fournisseur_price_fk_product FOREIGN KEY (fk_product) REFERENCES llx_product (rowid); DB_ERROR_CANNOT_CREATE
2013-01-21 09:07:42 WARN ::1 nologin upgrade DoliDBMysql::query SQL error: ALTER TABLE llx_categorie_fournisseur ADD CONSTRAINT fk_categorie_fournisseur_categorie_rowid FOREIGN KEY (fk_categorie) REFERENCES llx_categorie (rowid); DB_ERROR_CANNOT_CREATE
2013-01-21 09:07:42 WARN ::1 nologin upgrade DoliDBMysql::query SQL error: ALTER TABLE llx_categorie_fournisseur ADD CONSTRAINT fk_categorie_fournisseur_fk_soc FOREIGN KEY (fk_societe) REFERENCES llx_societe (rowid); DB_ERROR_CANNOT_CREATE
2013-01-21 09:07:42 WARN ::1 nologin upgrade DoliDBMysql::query SQL error: ALTER TABLE llx_propal ADD CONSTRAINT fk_propal_fk_user_author FOREIGN KEY (fk_user_author) REFERENCES llx_user (rowid); DB_ERROR_CANNOT_CREATE
2013-01-21 09:07:42 WARN ::1 nologin upgrade DoliDBMysql::query SQL error: ALTER TABLE llx_propal ADD CONSTRAINT fk_propal_fk_user_valid FOREIGN KEY (fk_user_valid) REFERENCES llx_user (rowid); DB_ERROR_CANNOT_CREATE
2013-01-21 09:07:42 WARN ::1 nologin upgrade DoliDBMysql::query SQL error: ALTER TABLE llx_propal ADD CONSTRAINT fk_propal_fk_user_cloture FOREIGN KEY (fk_user_cloture) REFERENCES llx_user (rowid); DB_ERROR_CANNOT_CREATE
2013-01-21 09:07:42 WARN ::1 nologin upgrade DoliDBMysql::query SQL error: ALTER TABLE llx_propal ADD CONSTRAINT fk_propal_fk_projet FOREIGN KEY (fk_projet) REFERENCES llx_projet (rowid); DB_ERROR_CANNOT_CREATE
2013-01-21 09:07:43 WARN ::1 nologin upgrade DoliDBMysql::query SQL error: ALTER TABLE llx_commande ADD CONSTRAINT fk_commande_fk_user_author FOREIGN KEY (fk_user_author) REFERENCES llx_user (rowid); DB_ERROR_CANNOT_CREATE
2013-01-21 09:07:43 WARN ::1 nologin upgrade DoliDBMysql::query SQL error: ALTER TABLE llx_commande ADD CONSTRAINT fk_commande_fk_user_valid FOREIGN KEY (fk_user_valid) REFERENCES llx_user (rowid); DB_ERROR_CANNOT_CREATE
2013-01-21 09:07:43 WARN ::1 nologin upgrade DoliDBMysql::query SQL error: ALTER TABLE llx_commande ADD CONSTRAINT fk_commande_fk_user_cloture FOREIGN KEY (fk_user_cloture) REFERENCES llx_user (rowid); DB_ERROR_CANNOT_CREATE
2013-01-21 09:07:43 WARN ::1 nologin upgrade DoliDBMysql::query SQL error: ALTER TABLE llx_commande ADD CONSTRAINT fk_commande_fk_projet FOREIGN KEY (fk_projet) REFERENCES llx_projet (rowid); DB_ERROR_CANNOT_CREATEPJ: logs complets de migration 3.1.1 -> 3.2.0
http://cjoint.com/?CAvkx2Cooa6
Non la table llx_categorie_societe n’est pas abandonnée ! Elle permet les liens entre llx_societe et llx_categorie.
Avez vous tenté une réparation de votre base ? Question bête, avez suffisament de droits pour modifier la structure des tables ? Les erreurs sont sur les ALTER TABLE
Si vous installez une instance en 3.1.1 toute propre, la migration fonctionne t-elle ?
En effet j’ai les droit appropriés. Je viens de faire une tentative d’installation de la 3.1.1 à partir de zéro avec une base toute aussi vide et… 
Connexion au serveur : localhost OK
Version de la base 5.5.29-1
Nom de la base de données dolitest
Création des tables et des clés primaires OK
Création des clés étrangères et des index pour la table llx_categorie_societe.key
Request 215 : ALTER TABLE llx_categorie_societe ADD PRIMARY KEY (fk_categorie, fk_societe) Erreur SQL DB_ERROR_NOSUCHTABLE Table 'dolitest.llx_categorie_societe' doesn't exist
Création des clés étrangères et des index pour la table llx_categorie_societe.key
Request 216 : ALTER TABLE llx_categorie_societe ADD INDEX idx_categorie_societe_fk_categorie (fk_categorie) Erreur SQL DB_ERROR_NOSUCHTABLE Table 'dolitest.llx_categorie_societe' doesn't exist
Création des clés étrangères et des index pour la table llx_categorie_societe.key
Request 217 : ALTER TABLE llx_categorie_societe ADD INDEX idx_categorie_societe_fk_societe (fk_societe) Erreur SQL DB_ERROR_NOSUCHTABLE Table 'dolitest.llx_categorie_societe' doesn't exist
Création des clés étrangères et des index pour la table llx_categorie_societe.key
Request 218 : ALTER TABLE llx_categorie_societe ADD CONSTRAINT fk_categorie_societe_categorie_rowid FOREIGN KEY (fk_categorie) REFERENCES llx_categorie (rowid) Erreur SQL DB_ERROR_NOSUCHTABLE Table 'dolitest.llx_categorie_societe' doesn't exist
Création des clés étrangères et des index pour la table llx_categorie_societe.key
Request 219 : ALTER TABLE llx_categorie_societe ADD CONSTRAINT fk_categorie_societe_fk_soc FOREIGN KEY (fk_societe) REFERENCES llx_societe (rowid) Erreur SQL DB_ERROR_NOSUCHTABLE Table 'dolitest.llx_categorie_societe' doesn't exist
Création des fonctions OK
Chargement des données de référence OKPar conséquent y a-t-il un souci avec les fichiers sources que je viens de télécharger depuis le site ?
Bon apparemment les erreurs sont liées à un crash de mysql qui a copieusement corrompu le dictionnaire innodb. Plus qu’à réinitialiser mysql et à recharger toutes les bases gérées par le serveur. Mauvaise semaine…
Vous pouvez essayer de faire un CHECK TABLE nom_de_table.
Sinon faites une sauvegarde, supprimez la base corrompue, recreez la et restaurez.
Ca doit suffir si c’est juste un crash mysql
Déjà fait tout ça, hélas. C’est bien un souci innodb: je peux pas faire un DROP de la base sans planter mysql.
ERROR 2013 (HY000): Lost connection to MySQL server during query
Du coup je dois supprimer à chaque fois le répertoire de la base à la main pour pouvoir la recréer via mysql mais la création des tables plante toujours ensuite sur llx_categorie_societe. Ce n’est en fait probablement pas un pb avec Dolibarr mais c’est tombé sur lui et peut être sur d’autres bases.
Edit: je confirme, j’ai 3 bases sur 22 touchées à des degrés variables par cette corruption silencieuse de l’index innodb, dont malheureusement les deux bases Dolibarr
Pas sûr que les .frm (dico innodb) soit dans les dossiers des données mais je n’ai pas vérifié. Veillez à bien les supprimer également s’ils sont corrompus ! Attention ça concerne toutes les bases donc sauvegardes préalables !!!
Ensuite on peut forcer innodb à démarrer différemment pour permettre la sauvegarde etc. Mail là c’est plus « coton »
Bon courage
J’avance un peu.
Si je crée un base avec un nom jamais utilisé, je peux installer la v3.1.1 sans souci avec une base vierge. Je peux ensuite importer n’importe quelle base (prod ou test) dans cette installation fraîche et tout fonctionne. En revanche, si je tente une migration vers une 3.2.3, je me retrouve avec le message indiqué dans mon premier post. Et dans les logs j’ai:
Jan 23 10:51:06 jupiter mysqld: 130123 10:51:06 InnoDB: Error: in ALTER TABLE `dolib01test`.`llx_categorie_societe`
Jan 23 10:51:06 jupiter mysqld: InnoDB: has or is referenced in foreign key constraints
Jan 23 10:51:06 jupiter mysqld: InnoDB: which are not compatible with the new table definition.
En outrepassant le contrôle des foreign keys, la mise à jour passe et tout fonctionne SAUF si j’emploie le module complémentaire des catégories pour les sociétés. Là j’ai le message indiquant que la table n’existe pas et innodb crashe en indiquant un message de ce type dans les logs.
Jan 23 11:15:10 jupiter mysqld: 130123 11:15:10 [ERROR] Cannot find or open table dolib01test/llx_categorie_societe from
Jan 23 11:15:10 jupiter mysqld: the internal data dictionary of InnoDB though the .frm file for the
Jan 23 11:15:10 jupiter mysqld: table exists. Maybe you have deleted and recreated InnoDB data
Jan 23 11:15:10 jupiter mysqld: files but have forgotten to delete the corresponding .frm files
Jan 23 11:15:10 jupiter mysqld: of InnoDB tables, or you have moved .frm files to another database?
Jan 23 11:15:10 jupiter mysqld: or, the table contains indexes that this version of the engine
Jan 23 11:15:10 jupiter mysqld: doesn't support.
Jan 23 11:15:10 jupiter mysqld: See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html
Jan 23 11:15:10 jupiter mysqld: how you can resolve the problem.
D’après ces messages, je penche vraiment pour le cas des index incompatibles puisque je pars de zéro et que je recharge une base contenant les index actuels qui marchent en 3.1.1. Il faudrait probablement que 1/ je désactive le module des catégories 2/ je recharge une sauvegarde de toutes les tables SAUF llx_categorie_societe puis retenter une migration vers 3.2.3 afin de ne pas la corrompre et de ne pas plier la base ?
NB: Après chaque crash innodb sur llx_categorie_societe la base est corrompue et son nom ne pourra plus être employé.
Edit: donc il y a peut-être quand même un souci avec ce module complémentaire de catégories dans Dolibarr.
Ta config MySQL a peut être des paramètres spécifiques, de mon coté zéro soucis et j’utilise les catégories.
Le message est clair c’est bien un soucis de .frm
Histoire de s’assurer, pas de soucis avec le/les disques? Pas de fichiers pourris ?
Victoire ! 
ça marche et ensuite je peux ajouter la table (vierge) manquante au format 3.2.3 puis réactiver la gestion des catégories qui fonctionne à nouveau. Ouf!
Edit: pour recréer la table j’ai tout simplement employé un script issu de la sauvegarde d’une installation 3.2.3 vierge de données:
[code]
SET FOREIGN_KEY_CHECKS=0;
SET SQL_MODE=« NO_AUTO_VALUE_ON_ZERO »;
llx_categorie_societeDROP TABLE IF EXISTS llx_categorie_societe;
CREATE TABLE llx_categorie_societe (
fk_categorie int(11) NOT NULL,
fk_societe int(11) NOT NULL,
PRIMARY KEY (fk_categorie,fk_societe),
KEY idx_categorie_societe_fk_categorie (fk_categorie),
KEY idx_categorie_societe_fk_societe (fk_societe),
CONSTRAINT fk_categorie_societe_categorie_rowid FOREIGN KEY (fk_categorie) REFERENCES llx_categorie (rowid),
CONSTRAINT fk_categorie_societe_fk_soc FOREIGN KEY (fk_societe) REFERENCES llx_societe (rowid)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
SET FOREIGN_KEY_CHECKS=1;[/code]
Curieux tout de même mais heureux que tu sois dépanné.
J’ai refait le test comme indiqué ci-dessus sur une copie de l’environnement de prod et le problème disparaît aussi. C’est donc définitivement résolu pour moi Merci.
Edit: étant donné que les bases prod et test ont une origine commune qui remonte à dolibarr 1.x, je ne suis pas outre-mesure surpris que le bug/crash ait la même cause.
