Mouai, ça pue le cafard à plein nez cette procédure de mise à jour des tables.
Je pense que la mise à jour de 3.2.3 vers 3.3.x est boguée ou que SQL et ses contraintes INODB est pourave …
Au nom des développeurs Dolibarr qui mettent à disposition gratuitement ce forum pour vous exprimer et leur travail pour vous permettre d’avoir un logiciel simple de gestion :
vous remercient beaucoup pour votre troisième message comportant les jolies expressions de :
-ça pue le cafard
-est pourrave
et votre réponse très polie : « bien essayé » !
Payez votre support pour traiter vos interlocuteurs/contributeurs de la sorte.
Non non, rien de tout cela dans mon esprit et je vous remercie infiniment de votre première réponse.
Rien que de l’humour ! même si le problème me met dans une situation très délicate.
Donc désolé si cela a été mal perçu (et puis il ne faut pas prendre tout pour vous, je ne suis pas sur que vous soyez pour quelques chose dans ce problème particulier).
« ça pue le cafard » c’est tout simplement qu’il se peut qu’il y ai une erreur dans le code de migration. Et coté utilisateur je vous confirme ça pue.
Donc pourrave pour l’utilisateur. Mais n’y voyez aucune association avec le très bon travail des développeurs. L’erreur est humaine, il faut juste en trouver la cause.
Bien essayé, est dans la même veine, mais apparemment cet humour ne vous convient pas et je le regrette.
De plus, ça ne me dérange absolument pas de payer un support.
J’espère que ces quelques mots vont apaiser votre susceptibilité.
Et pour ajouter quelque chose de positif, n’oubliez pas que le fait de signaler ce pb à la communauté avec une résolution à la clef peut permettre à beaucoup d’utilisateurs / contributeur et développeurs de faire progresser la qualité du logiciel.
Désolé cette réaction n’implique que moi, mais bon… avouez que ça n’avance pas beaucoup le « shmilblick » ces adjectifs péjoratifs, et découragerait le premier venu de faire les tests pour mettre à jour (reporter le problème) et aller vers la 3.3 ou 3.3.1.
Désolé de ma susceptibilité, face à ce souci, je ne sais pas comment répondre et cela m’ennuie, un hébergeur/développeur sympa a fait les MAJ à ma place, sinon j’aurai comme vous pris le temps, et eu la présence d’esprit de poster ce bug…
Merci pour la communauté d’ailleurs.
N’ayant pas croisé ce bug dans d’autres topics, je pense que re-plancher sur le SQL de mise à jour, et/ou au pire d’enlever les contraintes qui donnent une « odeur de cafard » à la mise à jour serait un bon début peut-être, pour voir si ça sentirait meilleur ?
Bon pour faire avancer le fameux smilblick, j’ai commencé à regarder un peu le script.
Mais je ne maitrise pas trop le php. Moi c’est plutôt le coté système et le sql.
Donc je prends votre idée de supprimer du script les contraintes, et de droper cette partie car les contraintes existent déjà et sont seulement dropés et recrés, mais je n’arrive pas à situer ou se trouve les scripts qui sont exécutés.
J’ai bien identifié les scripts dans /…/htdocs/install/mysql/tables, mais a priori ce ne sont pas ces scripts qui sont exécutés.
Donc si quelqu’un sais ou se trouvent les scripts de migration (pour mysql), je veux bien l’info.
les script de migration sont dans /htdocs/install/mysql/migration.
pour passé d’une 3.2.x a 3.3.x c’est 3.2.0-3.3.0 qui est executé
Sur votre copie sauvegarde (car vous en avez fait une avant de lancé la migration, lancer les requette une par une avec un phpmyadmin et vous verrez là ou ca plante.
Personnes n’a remonté ce bug avant, cela ne veux pas dire qu’il n’existe pas, mais peut être que vous avez une configuration particuliére dans votre GED qui n’a pas été imaginé par les developpeurs.
D’aprés ce que je lis il y a quelque chose de pas propre, un fk_user_c dans llx_ecm_directories référence un llx_user.rowid qui n’existe pas.
Cela peux voiloir dire deux choses :
1/ Vous avez crée des enristrement a la min dans cette table
2/ un utilisateur a été supprimé. Cette contrainte permet justement d’évité de supprimer un utilisateur qui serait lié a un création
3/ Dans les precedente version de dolibarr cette colonne n’était pas remplis…
Un petit SELECT * FROM llx_ecm_directories WHERE fk_user_c IS NULL OR fk_user_c NOT IN (SELECT rowid FROM llx_user) vous donnera les lignes de llx_ecm_directories fautives.
J’avais donc identifié le bon script après quelques recherches et effectivement pour le cas c’est celui-ci :
/…/htdocs/install/mysql/migration/3.2.0-3.3.0.sql
Après vérification de la base de donnée sauvegardée, la table concernée par le problème de contrainte sur la table : llx_ecm_directories
La contrainte qui ne « passe pas » est la suivante :
ADD CONSTRAINT fk_ecm_directories_fk_user_c FOREIGN KEY (fk_user_c) REFERENCES llx_user (rowid);
Alors que la suivante passe correctement …?
Donc après vérification, mise en commentaire de la ligne (je sais c’est facile…)
–ALTER TABLE llx_ecm_directories ADD CONSTRAINT fk_ecm_directories_fk_user_c FOREIGN KEY (fk_user_c) REFERENCES llx_user (rowid);
Je vous ai posé en P.J le fichier corrigé si vous voulez du « tout fait ».
En attendant qu’une personne connaissant très bien dolibarr puisse trouver une explication à cette valeurt qui ne passe pas (dans mon cas) pour une migration entre dolibarr v3.2.3 et 3.3.1
Espérant avoir poser ma petite contribution pour ceux qui serait concerné par le même problème.
Merci de votre intervention.
Donc après vérification, je ne sais pas trop bien ce qui c’est passé sur la base, je n’avais effectivement plus accès à 3 répertoires.
Application de la requête, suppression des lignes de la base, et hop!! récupération des 3 répertoires et du contenu.
