Discussion :

[Bowen]

Bonjour,

J'ai besoin de créer une clé primaire sur une table "prospect", rubrique "code_prospect".
Quand je tente de la créer, j'ai une erreur de doublon.
Le moteur me détecte MÉCHMI et MECHMI comme des doublons.

J'ai besoin que MÉCHMI et MECHMI soient considérés comme différents, mais que Mechmi et MECHMI soient considérés identiques.

Je pense qu'il existe un interclassement capable de gérer ce cas, mais malgré pas mal de recherches et d'essais, je ne trouve pas.

Savez-vous quel interclassement gère ça correctement ?

Interclassement actuel : latin1_swedish_ci

[punkoff]

Bonjour,

Il est fortement déconseillé de créer une clef primaire sur une colonne significative (qui est un varchar qui plus est ...)

De plus cette clef primaire manque de stabilité.
Quid des cas d'un client qui change de nom suite à un mariage, ou qu'une coquille se soit inséré dans ce même nom ?


Bref lisez cet article : http://sqlpro.developpez.com/cours/clefs/

Ca ne résoudra pas le problème initiale, mais au moins ca sera un peu mieux modélisé.


Pour le problème de collation vérifiez bien sous quelle collation est votre table / colonne / parametre par défault / etc...


Une autre piste pour vérifier les égalités serai d'utiliser ce genre de requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT STRCMP((SELECT ('Foo') COLLATE utf8_general_ci),(SELECT ('Föö') COLLATE utf8_general_ci));

[Bisûnûrs]

La collation latin1_general_cs a l'air de faire le travail :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SELECT _latin1 "mechi" COLLATE latin1_general_cs = _latin1 "MECHI" COLLATE latin1_general_cs;
# 0
SELECT _latin1 "mechi" COLLATE latin1_general_cs = _latin1 "méchi" COLLATE latin1_general_cs;
# 0
SELECT _latin1 "mechi" COLLATE latin1_general_cs = _latin1 "mechi" COLLATE latin1_general_cs;
# 1

[aieeeuuuuu]

essayez cp1256_general_ci

Mais comme dit par Punkoff, c'est une mauvaise clef primaire, plutôt une clef alternative.

[Bowen]

Mauvaise clé primaire... oui, mais je n'ai pas le choix !

Cette base est la réplique (synchronisée) d'une base en Access.
La clé primaire de la table dans Access est code_prospect.
Elle est clé étrangère dans d'autres tables qui seront synchronisées aussi. (devis, commandes, etc.)

Pour la latin1_general_cs, ça ne marche pas, enfin pas tout à fait.

MySQL me repère bien MÉCHMI et MECHMI comme différents (ce que je veux),
mais Mechmi et MECHMI sont aussi différents (ce que je ne veux pas).

Il me faut trouver un interclassement sensible aux accentuations, mais pas à la casse.

-----------------------------------------------------------------------------------------------------
Méthode utilisée pour tester, après avoir fait le changement sur la rubrique code_prospect
SELECT *
FROM prospect
--WHERE code_prospect = 'MECHMI' --> renvoie une ligne [ OK]
--WHERE code_prospect = 'mechmi' --> ne renvoie pas de ligne [devrait en renvoyer une]
--WHERE code_prospect = 'MÉCHMI' --> renvoie une ligne [OK]
--WHERE code_prospect = 'Méchmi' --> ne renvoie pas de ligne [devrait en renvoyer une]

[Bisûnûrs]

Ah pardon, j'avais mal lu, donc il faut remplacer cs (case-sensitive) par ci (case-insensitive).

[Bowen]

Hum,

En faisant des essais, j'ai vu l'infobulle sur les options de la liste déroulante.
C'est latin1_general_ci qu'il fallait.
L'infobulle dit "insensible à la casse".
Le CI doit être pour "case insensitive".

Mon problème est résolu, merci.

[Bowen]

Posts croisés, merci Bisûnûrs.
Tagué résolu.