dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-dev] Decalage dans table de constante


From: Benoit Mortier
Subject: Re: [Dolibarr-dev] Decalage dans table de constante
Date: Sun, 12 Sep 2004 20:30:30 +0200
User-agent: KMail/1.6.2

Le dimanche 12 Septembre 2004 19:11, Rodolphe Quiédeville a écrit :
> Benoit Mortier a écrit :
> > Le dimanche 12 Septembre 2004 14:50, Rodolphe Quiédeville a écrit :
> >>Benoit Mortier a écrit :
> >>>Le samedi 11 Septembre 2004 20:33, Rodolphe Quiédeville a écrit :
> >>>>Benoit Mortier a écrit :
> >>>>>Le vendredi 10 Septembre 2004 16:28, Rodolphe Quiedeville a écrit :
> >>>>>>Salut Benoit,
> >>>>>>
> >>>>>>J'ai lu ceci dans les logs CVS,
> >>>>>>
> >>>>>>attention tout les autres pays sont decales d'un rang !
> >>>>>>* mysql/data/data.sql 1.111 (changed +21 -21, diff)
> >>>>>>
> >>>>>>
> >>>>>>Qu'en est-il de cette modif lors de la migration d'une install en
> >>>>>>prod, j'ai un peu peur que cela casse tout, non ?
> >>>>>
> >>>>>c'est possible, c'etait necessaire pour postgresql car rowid ne peut
> >>>>>pas etre deux fois 2.
> >>>>>
> >>>>>Je peux le laisser dans pgsql/data.sql, et remettre comme c'etait
> >>>>>avant dans mysql/data.sql en attendant d'etudier le probleme.
> >>>>
> >>>>Il faut une cohérence entre pgsql et mysql pas question d'avoir des
> >>>>valeurs de constantes différentes dans les 2 bases, il doit etre
> >>>>possible de passer de l'une a l'autre.
> >>>
> >>>tout a fait d'accord car on ce moment on passe de l'une a l'autre pour
> >>>faire le portage vers postgresql ;-)
> >>>
> >>>>Mais je ne comprends pas ce problème de 2 fois 2.
> >>>
> >>>je ne peux pas mettre deux fois le rowid a 2 sous postgresql a cause
> >>> de la definition de la table
> >>>
> >>>
> >>>create table llx_c_pays
> >>>(
> >>>  rowid    SERIAL PRIMARY KEY,
> >>>  lang     varchar(8)   default 'all' not null,
> >>>  libelle  varchar(25),
> >>>  code     char(2) NOT NULL,
> >>>  active   smallint default 1  NOT NULL
> >>>);
> >>>
> >>>insert into llx_c_pays (rowid,libelle,code) values (2, 'Belgique',
> >>>'BE');
> >>>insert into llx_c_pays (rowid,libelle,code) values (2, 'Belgie',
> >>>'BE');
> >>>
> >>>SQL error:
> >>>ERREUR:  Une clé dupliquée rompt la contrainte unique
> >>> «llx_c_pays_pkey»
> >>>
> >>>>Si une modification de constante comme celle-ci est incontournable il
> >>>>faut alors fournir un script de mis à jour de la base que l'on
> >>>>intégrera dans la prochaine release.
> >>>
> >>>donc il faut que je laisse belgique a 2 et Belgie a 3, je vais etudier
> >>>le probleme cette semaine et je fournirait un script si necessaire.
> >>
> >>Oui mais je ne vois pas pourquoi tu voulais mettre le rowid à 2 pour
> >> les 2 valeurs.
> >
> > c'est une erreur qui traine depuis longtemps ;-)
> >
> >>Utilises plutot le système de traduction plutot que de mettre toutes
> >> les langues dans la table.
> >
> > malheureusement en blegique nous avons trois langues officielles
> >
> > Français, Neerlandais, Allemand ;-)
> >
> > donc fr_BE, nl_BE et pour le troisieme je ne sais pas je dois donc
> > permettre au neerlandophones d'avoir le programme dans leur langue d'ou
> > la neccessite de nl_BE
>
> Oui je comprends bien cela mais je ne comprends pas pourquoi tu veux
> mettre dans la table des pays les traductions des noms de pays ?
> La table des pays doit contenir la liste des pays uniquement après on
> choisit arbitrairement les libellés incluts dans la table et l'affichage
> se fait par les méthodes d'internationalisation.

ok je viens de comprendre ;-) je vais donc revenir en arriere et regarder du 
cote de l'internationalisation pour mon cas complexe ;-)

-- 
Benoit Mortier
OpenSides sprl
Linux Engineer




reply via email to

[Prev in Thread] Current Thread [Next in Thread]