Witam,

mam problem przy jednej tabeli i zastanawiam się co może powodować dziwną sytuację. Mianowicie przy dodaniu do tabeli frazy bez polskich znaków i próba dodania takiej samej z polskimi znakami powoduje wywalenie 1062 i niemożność dodania takowego rekordu.

Tabela:

[SQL] pobierz, plaintext 
CREATE TABLE `frazy` (
	`id_oph` INT(11) NOT NULL AUTO_INCREMENT,
	`hash` CHAR(10) DEFAULT NULL COLLATE 'utf8_unicode_ci',
	`phrase` VARCHAR(228) DEFAULT NULL COLLATE 'utf8_unicode_ci',
	PRIMARY KEY (`id_oph`),
	UNIQUE INDEX `hash_phrase` (`hash`, `phrase`)
)
COLLATE='utf8_unicode_ci'
ENGINE=MyISAM
[SQL] pobierz, plaintext 

Połączenie z bazą zawiera:

[PHP] pobierz, plaintext 
mysql_select_db($db_name,$mysql);
 
mysql_query("SET NAMES 'utf8'");
mysql_query('SET CHARACTER SET utf8_unicode_ci');
mysql_query('SET CHARACTER_SET_RESULTS="utf8"');
mysql_query("SET time_zone = 'Europe/Warsaw';");
[PHP] pobierz, plaintext 

Ktoś zna przyczynę, dlaczego MySQL traktuje część polskich znaków jako niediakrytyczne?
Z tego co zauważyłem nie dotyczy to wszystkich znaków, np. ł nie łapie, natomiast ś, ą czy ó już wywala jako duplikat.

Proponuję zmienić typ porównywania dla pola `phrase` na utf8_polish_ci

To pomogło, pytanie dlaczego unicode_ci nie rozróżnia tych znaków, chociaż powinien?

Co do zmiany, zamienię na utf8_bin, z tego względu, że trzymam tam też słowa w innych językach (np. niemieckie).

Dokumentacja nie precyzuje tego zbyt dokładnie:
"utf8_general_ci collation are faster, but slightly less correct"... slightly less to nie jest pojęcie, którym posługuje się inżynier i które oznacza, że projektanci MySQL też nie bardzo wiedzą dlaczego tak się dzieje Jest tam dalej przykład kilku różnych liter rozpoznawanych jako takie same. Trzeba z tym po prostu żyć, albo tak jak wykombinowałeś - zmienić kodowanie na utf8_bin.