---

Jeg er stødt på et lidt mærkeligt problem med MySQL. Kort fortalt
bliver f.eks. é = e når der skal sammenlignes primary keys.

Problemet:
Opret en tabel med et primary key felt:
CREATE TABLE `test` (
`testkey` varchar(255) character set latin1 NOT NULL default '',
PRIMARY KEY (`testkey`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Indsæt værdier:
INSERT INTO test VALUES ('e')
INSERT INTO test VALUES ('é')

Fejl: 1062 - Duplicate entry 'é' for key 1

Serveren er en MySQL 5.0.19-nt på en Windows XP maskine. Også testet
på 5.0.18. Jeg har prøvet med flere forskellige tegnsæt og både
innodb og myisam tabeltype. Desuden afprøvet med flere forskellige
klienter. Jeg har desuden søgt på bugs.mysql.com men har ikke fundet
noget der minder om.

MySQL 4.0, også på Windows, har ikke denne fejl.

Er det en fejl i min opsætning eller er det en bug i MySQL ?

mvh
Henrik Stidsen

---

"Henrik Stidsen" <henrikstidsen@gmail.com> writes:

> Er det en fejl i min opsætning eller er det en bug i MySQL ?

Du har dansk locale aktivt?

--
Thorbjørn Ravn Andersen

---

>> Er det en fejl i min opsætning eller er det en bug i MySQL ?

>Du har dansk locale aktivt?

Det er en dansk Windows og tabellens collate setting er sat til dansk.
Er der andre steder den slags kan ændres ?

---

"Henrik Stidsen" <henrikstidsen@gmail.com> writes:

> >Du har dansk locale aktivt?
>
> Det er en dansk Windows og tabellens collate setting er sat til dansk.
> Er der andre steder den slags kan ændres ?

Ingen anelse, men det lyder som det oplagte problem.

Hvorfor er e iøvrigt forskelligt fra è

--
Thorbjørn Ravn Andersen

---

On 16 Mar 2006 00:40:34 -0800, "Henrik Stidsen"
<henrikstidsen@gmail.com> wrote:

>Jeg er stødt på et lidt mærkeligt problem med MySQL. Kort fortalt
>bliver f.eks. é = e når der skal sammenlignes primary keys.

Det er ikke en fejl.

Din primary key er af typen varchar, og derfor foretages der en
tekstmæssig sammenligning - ikke en binær sammenligning. Det vil fx
også betyde at "e" er lig med "E".

Du kan angive feltet til at være binary - fx varchar(255) binary -
hvilket så igen er en shortcut for at bruge den tilsvarende
binary-collation under det gældende tegnsæt (fx latin1_bin eller
utf8_bin).

--
- Peter Brodersen
Find dig selv: http://map.ter.dk/

---

Henrik Stidsen skrev:

> e og E er også samme tegn, det er e og é ikke

Det er et definitionsspørgsmål. I MSSQL kan man vælge forskellige
typer af sorteringsnøgler (collations) for et sprogområde (fx
dansk/norsk) - og her kan man bl.a. vælge om nøglen skal være
versalfølsom (CS/CI) og accentfølsom (AS/AI). Jeg kender ikke til
mulighederne i MySQL, men der er ikke pr. definition noget forkert
i at vælge enhver af de fire kombinationsmuligheder (CS+AS, CS+AI,
CI+AS, CI+AI) som standard.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

> Hvorfor er e iøvrigt forskelligt fra è

Vel mest fordi det er forskellige tegn i tegntabellen - .NET, som jeg
benytter til det program der indsætter data, skelner mellem e og é
hvilket giver problemet når MySQL ikke gør.

---

> Det er ikke en fejl.

Hvis det ikke er en fejl, er det så en fejl at MySQL 4 skelner mellem
de to tegn ?

>Din primary key er af typen varchar, og derfor foretages der en
>tekstmæssig sammenligning - ikke en binær sammenligning. Det vil fx
>også betyde at "e" er lig med "E".

e og E er også samme tegn, det er e og é ikke - og som sagt, MySQL 4
(og .NET iøvrigt...) skelner mellem e og é, hvorfor gør 5.0 så ikke
?

Jeg kan, tilsyneladende, ikke bruge binary operatoren på et varchar
felt, men det ser ud til at virke hvis jeg benytter varbinary istedet
for varchar. Om der så er andre ulemper der ved jeg ikke lige...

mvh
Henrik Stidsen

---

On 17 Mar 2006 00:22:10 -0800, "Henrik Stidsen"
<henrikstidsen@gmail.com> wrote:

>> Det er ikke en fejl.
>Hvis det ikke er en fejl, er det så en fejl at MySQL 4 skelner mellem
>de to tegn ?

MySQL 4.0 eller 4.1? Collations blev indført i 4.1, så her tror jeg
også, du med en passende collation kan vælge at skelne.

>e og E er også samme tegn, det er e og é ikke - og som sagt, MySQL 4
>(og .NET iøvrigt...) skelner mellem e og é, hvorfor gør 5.0 så ikke
>?

e og E er to forskellige tegn, som man ud fra forskellige
sammenlignings-definitioner kan vælge at betragte som ét og samme
tegn. Denne sammenlignings-lighed har rigtigt nok været normen i en
lang række systemer (hvor é måske er faldet uden for).

Men vælger du fx en binær collation, vil e og E også være to
forskellige tegn.

>Jeg kan, tilsyneladende, ikke bruge binary operatoren på et varchar
>felt, men det ser ud til at virke hvis jeg benytter varbinary istedet
>for varchar. Om der så er andre ulemper der ved jeg ikke lige...

Hvilken MySQL kan du ikke det i?
   CREATE TABLE foo (id VARCHAR(20) BINARY);
... virker fint i MySQL 5.0. En efterfølgende show create table giver
så her:

CREATE TABLE `foobar` (
`id` varchar(20) character set latin1 collate latin1_bin default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_danish_ci;

Med andre ord, BINARY er blot en shortcut for den tilsvarende binære
collation (fx latin1_bin) for det aktuelle charset.

VARBINARY() er så en felttype for sig.

--
- Peter Brodersen
Find dig selv: http://map.ter.dk/

---

Peter Brodersen wrote :
>>> Det er ikke en fejl.
>> Hvis det ikke er en fejl, er det så en fejl at MySQL 4 skelner mellem
>> de to tegn ?

> MySQL 4.0 eller 4.1? Collations blev indført i 4.1, så her tror jeg
> også, du med en passende collation kan vælge at skelne.

4.0.20

> Med andre ord, BINARY er blot en shortcut for den tilsvarende binære
> collation (fx latin1_bin) for det aktuelle charset.

Så er det det der har snydt mig - og mit "fine" software til at snakke
med databasen.

> VARBINARY() er så en felttype for sig.

Men den giver det resultat jeg skal bruge :)

--
Henrik Stidsen - http://henrikstidsen.dk/
"Advertising is the art of convincing people to spend money they don't
have for something they don't need." - Will Rogers