Re: [Dolibarr-dev] Migration 2.1.0-2.2.0 - Problème foreign key sur llx_societe.idp

[Yannick Warnier]

Oui oui, d'office. C'est ce dont je venais de me rendre compte (que
phpMyAdmin ne les affiche pas) et je suis occupé à chercher dans le dump
(on a fait le même raisonnement).

Pour l'info, notre install est en effet assez vieille et je retrouve les
lignes suivantes (je les mets en entier, c'est la meilleure façon de
voir quelle table et quelle clef):


ALTER TABLE `llx_fichinter`
  ADD CONSTRAINT `fichinter_fk_soc_idp` FOREIGN KEY (`fk_soc`)
REFERENCES `llx_societe` (`idp`);

ALTER TABLE `llx_socpeople`
  ADD CONSTRAINT `socpeople_fk_soc_idp` FOREIGN KEY (`fk_soc`)
REFERENCES `llx_societe` (`idp`);

Voilà, c'était tout. Il a donc suffi d'un:
ALTER TABLE llx_fichinter DROP FOREIGN KEY fichinter_fk_soc_idp;
ALTER TABLE llx_socpeople DROP FOREIGN KEY socpeople_fk_soc_idp;

puis de reprocéder à l'upgrade pour que ça s'arrange.

Tiens, dans le fond, est-ce qu'on peut appliquer le script d'upgrade
plusieurs fois d'affilée sans trop de dégâts? Un rapide survol semble me
faire comprendre que les insertions se font toujours avec des IDs
prédéfinis, donc normalement ça devrait passer, mais je me demande si
c'est fait pour ou si c'est juste un hasard?

Merci Laurent,

Yannick


Le lundi 07 janvier 2008 à 01:44 +0100, Eldy a écrit :
> Errata: Je voulais dire phpMyAdmin mais en fait non phpMyAdmin n'affiche 
> pas les clés étrangères.
> 
> Donc pour les trouver et supprimer les clé étrangères qui posent pb sur 
> la migration vers 2.2, tu fais un dump de ta base par "mysqldump" dans 
> un fichier.
> 
> Puis tu fais une recherche dans le fichier des chaines du genre:
> 
> CONSTRAINT `xxxxxxx` FOREIGN KEY (`zzzzz`) REFERENCES `llx_societe` 
> (`rowid`)
> 
> Alors xxxxxxx est le nom d'une foregin key qui point sur le chp rowid de 
> la table llx_société.
> Tu peux donc maintenant que son nom est connu, l'effacer par
> 
> ALTER TABLE /|yyyyy|/ DROP FOREIGN KEY /|xxxxxx|/;
> 
> avec yyyyy qui est le nom de la table dont l'ordre create se trouve au dessus
> de la ligne de foreign key trouvée dans le fichier dump.
> 
> Attention il y en a plusieurs...
> Il faut toutes détruire celles qui font référence sur "REFERENCES 
> `llx_societe` (`rowid`)"
> 
> 
> 
> Yannick Warnier a écrit :
> > Le dimanche 06 janvier 2008 à 18:54 +0100, Yannick Warnier a écrit :
> >   
> >> Salut,
> >>
> >> En essayant de migrer plusieurs systèmes Dolibarr 2.1.0 vers 2.2.0, je
> >> tombe sur le même problème partout. En gros, le script de migration
> >> entre ces deux versions essaie de faire (au moins) ceci:
> >>
> >> ALTER TABLE `llx_societe` CHANGE `idp` `rowid` integer AUTO_INCREMENT;
> >> ALTER TABLE `llx_socpeople` CHANGE `idp` `rowid` integer AUTO_INCREMENT;
> >>
> >> Malheureusement, chez moi l'opération échoue avec une erreur Mysql
> >> (errno 150) qui est définie comme une erreur de clef étrangère (foreign
> >> key error).
> >>
> >> Est-ce que personne d'autre n'a eu le problème? Est-ce qu'il y a un mode
> >> spécial pour MySQL que je peux activer avant de faire la migration pour
> >> lui dire d'ignorer les foreign keys le temps du script?
> >>     
> >
> > J'ai essayé "set foreign_key_checks=0;" au début du script de migration
> > mais ça ne fonctionne pas non plus.
> >
> > Yannick
> >
> >
> >
> > _______________________________________________
> > Dolibarr-dev mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
> >   
> 
>