Discussion :

[goddet]

Bonjour à tous,

J'ai un petit soucis de collation sous MySQL 5.0.22
Alors j'ai fait les actions suivantes :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
CREATE TABLE `table_test` (
  `id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
  `nom` VARCHAR(32)  NOT NULL ,
  PRIMARY KEY (`id`)
)CHARSET latin1 COLLATE latin1_german1_ci;
 
INSERT INTO table_test(nom) VALUE('pépé');
 
SELECT * FROM table_test WHERE nom='pepe';

Là il me retourne rien, pourtant j'ai lu que la collation latin1_german1_ci était insensible à la case et aux accents!
J'ai essayé aussi de passé en utf8 :

Code :

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

1
2
3
 
ALTER TABLE table_test
CHARSET utf8 COLLATE utf8_unicode_ci;

Toujours rien (pourtant MySQL me retourne bien quelque chose quand je passse dans le select pépé!).
J'ai aussi vérifier le fichier my.ini (ces 2 lignes sont bien présentes) :
default-character-set=latin1
default-collation=latin1_german1_ci

Je ne vois pas d'ou vient le problème!

Merci d'avance.
David

[Adjanakis]

Bonjour,

latin1_german_ci est bien insensible à la casse, d'où le 'ci', mais il n'est pas insensible aux accents. Il permet juste de pouvoir trier les accents convenablement.

[goddet]

Merci pour cette réponse!
Je pensais que latin1_german1_ci était insensible aux accents car je l'ai lu ici.
De même que utf8 est bien insensible aux accents, non? Car la requete ne retourne rien même avec ce jeu!
Je suis un peu paumé la!

[Adjanakis]

Après vérification, latin1_german1_ci est bien insensible aux accents pour l'égalité ( décidément j'en dis des bétises aujourd'hui).

Du coup, j'imagine que la colonne en question ne doit pas avoir la bonne collation. Pourrais-tu faire un SHOW CREATE TABLE pour voir comment est la table ?

[Antoun]

J'ai testé ton code et j'obtiens bien Pépé en latin1_german1_ci, dont je confirme donc l'insensibilité aux accents (testé en 5.0.37 sous Linux et 5.1.19 sous Windows). ça peut être un problème de version, mais j'en doute (j'avais dû faire les tests pour mon article en 5.0.21).

Peux-tu faire le test suivant ?

Code :

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

SELECT COLLATION(nom) FROM table_test ;

Quant à ton ALTER TABLE, il ne change rien, sinon le jeu de caractères des futures colonnes que tu créeras ensuite dans la table... autrement dit, c'est le jeu de caractères PAR DEFAUT de la table, mais ça ne change pas celui des colonnes déjà existantes.

[goddet]

Lorsque je fais

Code :

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

1
2
 
SELECT COLLATION(nom) FROM table_test ;

J'obtiens ce résultat :

Code :

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

1
2
3
4
5
6
 
+-------------------+
| COLLATION(nom)    |
+-------------------+
| latin1_german1_ci |
+-------------------+

Et j'ai toujours "Empty set" comme réponse à ma requete!

De plus la commande

Code :

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

1
2
 
SHOW CREATE TABLE table_test;

Me retourne :

Code :

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

1
2
3
4
5
6
 
| table_test | CREATE TABLE `table_test` (
  `id` int(11) unsigned NOT NULL auto_increment,
  `nom` varchar(32) collate latin1_german1_ci NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci |

[goddet]

Bon je pense avoir vu l'origine du problème!
J'ai ajouté le nom pépé sous MS-Dos!!!!!! ( Quel crétin! Ms-Dos est en ASCII il me semble!)
Donc c'est sur qu'il n'a pas compris les accents sur pépé (le é = , quand j'ai testé sous phpmyadmin!)
Donc la ça marche : ma requete retourne bien ce qu'il faut!
Merci quand même pour les réponses.

[Antoun]

dans le client texte sous MS-DOS, il faut généralement passer l'ordre

Code :

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

SET NAMES latin1

afin que les accents soient correctement interprétés (il y a un encadré là-dessus dans mon article, pour les détails).