---

Ifm ordbogen, der har været lidt snak om i andre grupper, og stadig
arbejdes på, har jeg dunket hovedet mod en mur, jeg har lidt svært ved
at komme over...

Begreber og forklaringer, findes i to tabeller (mySQL):
Bergreberne:
anchor
begreb (unik)

Forklaringerne:
anchor (unik)
forklaring

(Der er et par attributter mere, men de er uvæsentlige i denne
sammenhæng).
Strukturen er valgt sådan, fordi det skal være muligt at referere
forskellige begreber til samme forklaring.
Problemet - det største - er, at når ordbogen skal vises
(http://bbsorensen.com/ordbog/?men=Ordbog) vil jeg have visningen
sorteret efter begrebet (visningen lige nu er sorteret efter anchor).
Men sådan at hvis der til samme anchor, findes flere begreber, skal de
komme umiddelbart efter, og ikke gentages der hvor de egentlig hører
til.
Er det forståeligt?

Jeg har f.eks en Forklaring, der hedder "En del af Danmark", den har
anchor Danmark.
Så har jeg begreber Jylland, Fyn, Aggersholm, Sjælland, Ærøskøbing,
Bornholm. De har også alle anchor Danmark.
Så derfor skal de i sorteringen alle findes efter hinanden, med
Aggersholm som det første, og de andre umiddelbart efter - uanset andre
begreber i databasen.

Nogen der kan gennemskue en måde at gøre det simpelt på?

Desuden er der et problem med sorteringen. Som man kan se, kommer Å før
Æ og Ø - og det var ikke sådan jeg lærte alfabetet....
Nogen forklaring på det?

Der er så et problem med validering også - men det tager jeg nok op i
en af de andre grupper, hvis jeg ikke får skovlen under det...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

On Thu, 09 Jun 2011 18:10:49 +0200, Birger Sørensen wrote:

> Men sådan at hvis der til samme anchor, findes flere begreber, skal de
> komme umiddelbart efter, og ikke gentages der hvor de egentlig hører
> til.

Desværre et stykke tid siden, jeg sidst har rodet med de analytiske
funktioner, men i Oracle bør det kunnne gøres på ca. denne måde, om jeg har
forstået dit problem ret:

select b.*
from begreb b,
(select begreb,
first_value(begreb) over (partition by anchor order by begreb) srt1,
row_number() over (partition by anchor order by begreb) srt2
from begreb) srt
where b.begreb = srt.begreb
order by srt.srt1, srt.srt2




--
What is life, except excuse for death,
or death, but an escape from life. -Ukendt

Fly Opera - http://opera.softwolves.dk

---

On 09-06-2011 18:10, Birger Sørensen wrote:
> Desuden er der et problem med sorteringen. Som man kan se, kommer Å før
> Æ og Ø - og det var ikke sådan jeg lærte alfabetet....
> Nogen forklaring på det?

Forkert brug af collation.
Står sikkert som utf8_general_ci eller noget i den stil.
Prøv at ændre til utf8_danish_ci (eller latin1_danish_ci, hvis din
collation er latin1)

---

Martin har bragt dette til verden:
> On 09-06-2011 18:10, Birger Sørensen wrote:
>> Desuden er der et problem med sorteringen. Som man kan se, kommer Å før
>> Æ og Ø - og det var ikke sådan jeg lærte alfabetet....
>> Nogen forklaring på det?
>
> Forkert brug af collation.
> Står sikkert som utf8_general_ci eller noget i den stil.
> Prøv at ændre til utf8_danish_ci (eller latin1_danish_ci, hvis din collation
> er latin1)

Hvilken af dem? ;>)
Der er en for hele databsen. Den er utf8_bin.
Det samme er collation for tabellen.
For attributterne er collationen latin1_bin.
Det er sådan jeg "plejer" at gøre, og det plejer at virke. Er så ikke
sikker på, at jeg har brugt alfabetisk sortering før.

Det er for tabellen, du mener collationen skal ændres?

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen formulerede Friday:
> Martin har bragt dette til verden:
>> On 09-06-2011 18:10, Birger Sørensen wrote:
>>> Desuden er der et problem med sorteringen. Som man kan se, kommer Å før
>>> Æ og Ø - og det var ikke sådan jeg lærte alfabetet....
>>> Nogen forklaring på det?
>>
>> Forkert brug af collation.
>> Står sikkert som utf8_general_ci eller noget i den stil.
>> Prøv at ændre til utf8_danish_ci (eller latin1_danish_ci, hvis din
>> collation er latin1)
>
> Hvilken af dem? ;>)
> Der er en for hele databsen. Den er utf8_bin.
> Det samme er collation for tabellen.
> For attributterne er collationen latin1_bin.
> Det er sådan jeg "plejer" at gøre, og det plejer at virke. Er så ikke sikker
> på, at jeg har brugt alfabetisk sortering før.
>
> Det er for tabellen, du mener collationen skal ændres?
>
> Birger

Det kostede lidt eksperimentering.
Ændring af collation for datafelterne gjorde udslagt.
De er nu latin1_danish_ci, og begreberne sorteres på dansk.

Så mangler jeg bare at sorteringen tage med, at dem med samme anchor,
skal komme efter hinanden...
Legede i går med GROUP BY - der kommer så kun et resultat for hvert
anchor.
Jeg havde forstillet mig noget med noget JOIN. Men mangler en god
forklaring af hvad den gør. Det virker kryptisk på mig. Måske skal der
bare studres lidt flittigere...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

On Fri, 10 Jun 2011 13:11:16 +0200, Birger Sørensen wrote:

> Så mangler jeg bare at sorteringen tage med, at dem med samme anchor,
> skal komme efter hinanden...

Ved srt1 grupperer vi begreberne efter anchor, så laves der en sortering
efter begreb inden i de enkelte grupper; vi tager det første begreb af dem
fra hver gruppe, og dette "sætter vi på" alle de andre begreber i samme
anchor-gruppe. Nu er vi i stand til at lave en sortering af anchor-grupper
alt efter hvad der kommer først af begreber inden i hver enkelt gruppe.
Dernæst i srt2 skal vi finde sorteringen internt i hver anchor-gruppe.
Dette gør vi ved igen at gruppere efter anchor og lave en sortering efter
begreb. Dette kan vi så slutteligt joine med det vi vil have sorteret,
altså joiner vi det på begreb-tabellen og laver sorteringen.

Jeg har lige hurtigt implementeret det i SQL Server, og her ser det sådan
ud (lidt mere omstændigt, da den ikke har first_value, men ellers samme
princip):

select b.*, srt.srt1, srt.srt2
from begreb b, (
select bb.bwegreb,
(select patrow1st.srt1
from (select bi.anchor, bi.bwegreb as srt1, row_number() over
(partition by bi.anchor order by bi.bwegreb) rnA from dbo.begreb bi)
patrow1st
where patrow1st.rnA = 1 and bb.anchor = patrow1st.anchor --corr
sub!
) srt1,
row_number() over (partition by bb.anchor order by bb.bwegreb)
srt2
FROM dbo.begreb bb
) srt
where b.bwegreb = srt.bwegreb
order by srt.srt1, srt.srt2


Eksempel:


begreb-tabellen:

anchor bwegreb
Danmark Fyn
Danmark Jylland
Danmark Aggersholm
Norge Oslo
Norge Brits
Sverige Aalhol
Sverige Cedersholm



forklaring-tabellen:

anchor forklaring
Sverige Forkalring om se
Norge Forkalring om no
Danmark Forklring om dk



patrow1st-tabellen:

anchor srt1 rnA
Danmark Aggersholm 1
Danmark Fyn 2
Danmark Jylland 3
Norge Brits 1
Norge Oslo 2
Sverige Alhom 1
Sverige Cedersholm 2



SRT-tabellen:

bwegreb srt1 srt2
Aggersholm Aggersholm 1
Fyn Aggersholm 2
Jylland Aggersholm 3
Brits Brits 1
Oslo Brits 2
Alhom Alhom 1
Cedersholm Alhom 2




Data sorteret:
anchor bwegreb srt1 srt2
Danmark Aggersholm Aggersholm 1
Danmark Fyn Aggersholm 2
Danmark Jylland Aggersholm 3
Sverige Alhom Alhom 1
Sverige Cedersholm Alhom 2
Norge Brits Brits 1
Norge Oslo Brits 2


--
What is life, except excuse for death,
or death, but an escape from life. -Ukendt

Fly Opera - http://opera.softwolves.dk

---

Efter mange tanker skrev Christian Bohr-Halling:
> On Fri, 10 Jun 2011 13:11:16 +0200, Birger Sørensen wrote:
>
>> Så mangler jeg bare at sorteringen tage med, at dem med samme anchor,
>> skal komme efter hinanden...
>
> Ved srt1 grupperer vi begreberne efter anchor, så laves der en sortering
> efter begreb inden i de enkelte grupper; vi tager det første begreb af dem
> fra hver gruppe, og dette "sætter vi på" alle de andre begreber i samme
> anchor-gruppe. Nu er vi i stand til at lave en sortering af anchor-grupper
> alt efter hvad der kommer først af begreber inden i hver enkelt gruppe.
> Dernæst i srt2 skal vi finde sorteringen internt i hver anchor-gruppe.
> Dette gør vi ved igen at gruppere efter anchor og lave en sortering efter
> begreb. Dette kan vi så slutteligt joine med det vi vil have sorteret,
> altså joiner vi det på begreb-tabellen og laver sorteringen.
>
> Jeg har lige hurtigt implementeret det i SQL Server, og her ser det sådan
> ud (lidt mere omstændigt, da den ikke har first_value, men ellers samme
> princip):
>
> select b.*, srt.srt1, srt.srt2
> from begreb b, (
> select bb.bwegreb,
> (select patrow1st.srt1
> from (select bi.anchor, bi.bwegreb as srt1, row_number() over
> (partition by bi.anchor order by bi.bwegreb) rnA from dbo.begreb bi)
> patrow1st
> where patrow1st.rnA = 1 and bb.anchor = patrow1st.anchor --corr
> sub!
> ) srt1,
> row_number() over (partition by bb.anchor order by bb.bwegreb)
> srt2
> FROM dbo.begreb bb
> ) srt
> where b.bwegreb = srt.bwegreb
> order by srt.srt1, srt.srt2
8X

Din tankegang er rigtig, og den kan jeg følge - det kniber så lidt med
at oversætte det til SQL. Det må være alderen der trykker (min altså).
Prøvede at kopiere din query, og får dette resultat:

You have an error in your SQL syntax; check the manual that corresponds
to your MySQL server version for the right syntax to use near
'(partition by bi.anchor order by bi.bwegreb) rnA from dbo.begreb bi)
patrow1st ' at line 6

Prøvede så at slå "partition by" og "over" op - men kan ikke finde
nogen af dem. Den første findes tilsyneladende slet ikke i MySQL
dokumentationen - den anden giver 143425 resultater, der vist handler
om alt fra "Sun Java System Application Server" til "Oracle Retail
Price Management Documentation Library", men ikke umiddelbart noget der
ligner SQL...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

On Fri, 10 Jun 2011 20:07:03 +0200, Birger Sørensen wrote:

> You have an error in your SQL syntax; check the manual that corresponds
> to your MySQL server version for the right syntax to use near
> '(partition by bi.anchor order by bi.bwegreb) rnA from dbo.begreb bi)
> patrow1st ' at line 6

Næ, ser ikke ud til, MySQL understøtter det. Så skal man til selv at
implementere det, og så er det knapt så simpelt som mit oprindelige forslag
i Oracle (og tildels SQL Server).

http://www.artfulsoftware.com/infotree/queries.php#1098
http://explainextended.com/2009/03/10/analytic-functions-first_value-last_value-lead-lag/

--
What is life, except excuse for death,
or death, but an escape from life. -Ukendt

Fly Opera - http://opera.softwolves.dk

---

Birger Sørensen formulerede spørgsmålet:
> Birger Sørensen formulerede Friday:
>> Martin har bragt dette til verden:
>>> On 09-06-2011 18:10, Birger Sørensen wrote:
>>>> Desuden er der et problem med sorteringen. Som man kan se, kommer Å før
>>>> Æ og Ø - og det var ikke sådan jeg lærte alfabetet....
>>>> Nogen forklaring på det?
>>>
>>> Forkert brug af collation.
>>> Står sikkert som utf8_general_ci eller noget i den stil.
>>> Prøv at ændre til utf8_danish_ci (eller latin1_danish_ci, hvis din
>>> collation er latin1)
>>
>> Hvilken af dem? ;>)
>> Der er en for hele databsen. Den er utf8_bin.
>> Det samme er collation for tabellen.
>> For attributterne er collationen latin1_bin.
>> Det er sådan jeg "plejer" at gøre, og det plejer at virke. Er så ikke
>> sikker på, at jeg har brugt alfabetisk sortering før.
>>
>> Det er for tabellen, du mener collationen skal ændres?
>>
>> Birger
>
> Det kostede lidt eksperimentering.
> Ændring af collation for datafelterne gjorde udslagt.
> De er nu latin1_danish_ci, og begreberne sorteres på dansk.
>
> Så mangler jeg bare at sorteringen tage med, at dem med samme anchor, skal
> komme efter hinanden...
> Legede i går med GROUP BY - der kommer så kun et resultat for hvert anchor.
> Jeg havde forstillet mig noget med noget JOIN. Men mangler en god forklaring
> af hvad den gør. Det virker kryptisk på mig. Måske skal der bare studres lidt
> flittigere...
>
> Birger

Og så alligevel ikke.
Med latin1_danish_ci, får jeg ikke lov at have ens begreber med
forskellig case.
Jeg vil godt oprette et begreb der hedder biodynamisk - men får ikke
lov, fordi der finde Biodynamisk i forvejen.
Hvordan får jeg den til både at sortere efter det danske alfabet, og
kende forskel på små og stor bogstaver?

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

"Birger Sørensen" <sdc@bbsorensen.com> skrev i en meddelelse
news:4df1fc29$0$315$14726298@news.sunsite.dk...
> Birger Sørensen formulerede Friday:
>> Martin har bragt dette til verden:
>>> On 09-06-2011 18:10, Birger Sørensen wrote:
>>>> Desuden er der et problem med sorteringen. Som man kan se, kommer Å før
>>>> Æ og Ø - og det var ikke sådan jeg lærte alfabetet....
>>>> Nogen forklaring på det?
>>>
>>> Forkert brug af collation.
>>> Står sikkert som utf8_general_ci eller noget i den stil.
>>> Prøv at ændre til utf8_danish_ci (eller latin1_danish_ci, hvis din
>>> collation er latin1)
>>
> Det kostede lidt eksperimentering.
> Ændring af collation for datafelterne gjorde udslagt.
> De er nu latin1_danish_ci, og begreberne sorteres på dansk.
>

Hvis du insisterer på en latin1_danish_cs, med forskel på A og a, så kan du
lave den selv:

http://dev.mysql.com/doc/refman/5.5/en/charset-collation-implementations.html

Men om det kræver administratorrettigheder på serveren, er jeg usikker på.

Leif

---

Og her er så en løsning - sådan da.

Jeg tager lige sorteringsproblematikken først.
Det er collation for datafelterne der styrer sorteringen af de enkelte
felter.
latin1_bin kender forskel på store og små bogstaver, men sorterer
forkert (Å kommer før Æ og Ø).
latin1_danish_ci har ikke forskel på store og små bogstaver, men
sorterer rigtigt.
Eftersom formålet er at udskifte dele af brugerens tekster, med link
til forklaringer af begreber, og disse vil være "case sensitive", er
latin1_danish_ci ubrugeligt.
Måske ville det kunne lade sig gøre, at skrive noget i PHP, der kan
bruges - men hastigheden er også en faktor, så jeg tror ikke at det er
en farbar vej.
Der er altså valgt, at bruge latin1.
Mht. den forkerte sortering, blev sorteringen i forvejen gjort på
UPPER() af begreberne, for at få en fornuftig opstilling - A og a samme
sted i oversigten.
Og løsningen var at bruge BIN(UPPER(begreb)) - så bliver latin1
sorteret korrekt, også på dansk.


Problemet med at få rækkerne ud sorteret efter begreb, men med begreber
med samme anchor efter hinanden, er egentlig ikke blevet løst.
Der anvendes denne:

SELECT st1.anchor, st2.over, st2.forklaring FROM
(SELECT anchor, begreb FROM ord_begreb) AS st1
JOIN
(SELECT anchor, over, forklaring FROM ord_forklar) AS st2
ON st2.anchor=st1.anchor ORDER BY BIN(UPPER(st1.begreb))

Den leverer anchor fra begrebstabellen med overskrift og forklaring fra
forklaringstabellen, sorteret efter begrebet - men den samler ikke ens
anchors.
Udvælgelsen bliver foretaget af PHP, ved for hvert anchor at at springe
dem over, der er blevet behandlet, og for dem der ikke er, at hente
begreb og sprog fra begrebstabellen, sorteret efter begreb

SELECT begreb, sprog FROM ord_begreb WHERE anchor=? ORDER BY
BIN(UPPER(begreb))

Det er formentlig ikke så effektivt (hurtigt) som hvis man kunne få den
til at sortere rigtigt i første hug.
Men det virker efter hensigten - her hos mig, tager det ca. 5s. at
hente og og vise de 500 begreber.

Jeg har forsøgt - både efter Christian Bohr-Halling's forslag, og hvad
jeg selv kunne komme på - men det insisterer på ikke at ville give et
brugbart resultat. Ikke at jeg har opgivet, men indtil videre, er det
som det er.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Det er collation for datafelterne der styrer sorteringen af de enkelte
> felter.
> latin1_bin kender forskel på store og små bogstaver, men sorterer
> forkert (Å kommer før Æ og Ø).
> latin1_danish_ci har ikke forskel på store og små bogstaver, men
> sorterer rigtigt.
> Eftersom formålet er at udskifte dele af brugerens tekster, med link
> til forklaringer af begreber, og disse vil være "case sensitive", er
> latin1_danish_ci ubrugeligt.

Lidt baggrund, dog uden at kende mySQL i bund.

Birger, du har sikkert gennem din tid stiftet bekendtskab med 'fænomenet'
Danish/Norwegian .. ?

Kendetegnet for Danish/Norwegian ( i forhold til andre) er, at netop ÆØÅ
kommer EFTER Z, hvor diverse 'accenter' i andre sprog sidestilles med
bogstavet selv.

Så 1) Du skal have fat i Danish/Norwegian collating sequence.

2) 'Efternavnet' _ci siger næsten sig selv ;) _C_ase _I_nsensitive.
Findes der ikke en _c eller en _cs ?


--
Med venlig hilsen
Stig Johansen

---

Efter mange tanker skrev Stig Johansen:
> Birger Sørensen wrote:
>
>> Det er collation for datafelterne der styrer sorteringen af de enkelte
>> felter.
>> latin1_bin kender forskel på store og små bogstaver, men sorterer
>> forkert (Å kommer før Æ og Ø).
>> latin1_danish_ci har ikke forskel på store og små bogstaver, men
>> sorterer rigtigt.
>> Eftersom formålet er at udskifte dele af brugerens tekster, med link
>> til forklaringer af begreber, og disse vil være "case sensitive", er
>> latin1_danish_ci ubrugeligt.
>
> Lidt baggrund, dog uden at kende mySQL i bund.
>
> Birger, du har sikkert gennem din tid stiftet bekendtskab med 'fænomenet'
> Danish/Norwegian .. ?
>
> Kendetegnet for Danish/Norwegian ( i forhold til andre) er, at netop ÆØÅ
> kommer EFTER Z, hvor diverse 'accenter' i andre sprog sidestilles med
> bogstavet selv.
>
> Så 1) Du skal have fat i Danish/Norwegian collating sequence.
>
> 2) 'Efternavnet' _ci siger næsten sig selv ;) _C_ase _I_nsensitive.
> Findes der ikke en _c eller en _cs ?

Jeg har rodet - dog kun i phpMyAdmin. Kan slet ikke finde en forklaring
der er forståelig (for mig) i doc for MySQL.
Og det er latin1_bin, som iflg mine begreber, burde gøre rigtigt - mmen
som sltså sætter Å før Æ og Ø, men ellers placere dem efter Z.
Der er desuden et hav af andre, som jeg ikke rigtig har lyst til at
kaste mig ud i at forsøge med. Der er mange karaktersæt, men kun med
navn - ikke hvad de faktisk indeholder. Og eftersom siden de skal
bruges med, er iso-8859, bør det vel være latin1. Dem er der mange af -
kun een der hedder latin_general_cs. Har ikke tænkt på at prøve den,
men det vil jeg.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen frembragte:
> Efter mange tanker skrev Stig Johansen:
>> Birger Sørensen wrote:
>>
>>> Det er collation for datafelterne der styrer sorteringen af de enkelte
>>> felter.
>>> latin1_bin kender forskel på store og små bogstaver, men sorterer
>>> forkert (Å kommer før Æ og Ø).
>>> latin1_danish_ci har ikke forskel på store og små bogstaver, men
>>> sorterer rigtigt.
>>> Eftersom formålet er at udskifte dele af brugerens tekster, med link
>>> til forklaringer af begreber, og disse vil være "case sensitive", er
>>> latin1_danish_ci ubrugeligt.
>>
>> Lidt baggrund, dog uden at kende mySQL i bund.
>>
>> Birger, du har sikkert gennem din tid stiftet bekendtskab med 'fænomenet'
>> Danish/Norwegian .. ?
>>
>> Kendetegnet for Danish/Norwegian ( i forhold til andre) er, at netop ÆØÅ
>> kommer EFTER Z, hvor diverse 'accenter' i andre sprog sidestilles med
>> bogstavet selv.
>>
>> Så 1) Du skal have fat i Danish/Norwegian collating sequence.
>>
>> 2) 'Efternavnet' _ci siger næsten sig selv ;) _C_ase _I_nsensitive.
>> Findes der ikke en _c eller en _cs ?
>
> Jeg har rodet - dog kun i phpMyAdmin. Kan slet ikke finde en forklaring der
> er forståelig (for mig) i doc for MySQL.
> Og det er latin1_bin, som iflg mine begreber, burde gøre rigtigt - mmen som
> sltså sætter Å før Æ og Ø, men ellers placere dem efter Z.
> Der er desuden et hav af andre, som jeg ikke rigtig har lyst til at kaste mig
> ud i at forsøge med. Der er mange karaktersæt, men kun med navn - ikke hvad
> de faktisk indeholder. Og eftersom siden de skal bruges med, er iso-8859, bør
> det vel være latin1. Dem er der mange af - kun een der hedder
> latin_general_cs. Har ikke tænkt på at prøve den, men det vil jeg.
>
> Birger

Og det er så prøvet og forkastet.
Den sorterer - som forventet/frygtet - Æ og Å, sammen med A'er og Ø
lige efter O.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Og det er latin1_bin, som iflg mine begreber, burde gøre rigtigt - mmen
> som sltså sætter Å før Æ og Ø, men ellers placere dem efter Z.

Nej, og ja.

'bin' er sikkert den binære værdi, hvor 'man' har lagt de danske tegn i
forkert rækkefølge.

Kig på:
http://en.wikipedia.org/wiki/ISO/IEC_8859-1
under _codepage_ layout.

Her kan du se, at Å = 197,Æ=198 samt Ø=216.

Dvs. _binær_ sortering vil give ÅÆØ i denne rækkefølge.

Årsagen skal jeg lade være usagt, men 'gamle' folk husker tydeligt at ø/Ø
var 'glemt' i de oprindelige codepages, og gav cent/Yen tegn.


> Der er desuden et hav af andre, som jeg ikke rigtig har lyst til at
> kaste mig ud i at forsøge med. Der er mange karaktersæt, men kun med
> navn - ikke hvad de faktisk indeholder. Og eftersom siden de skal
> bruges med, er iso-8859, bør det vel være latin1.

Du skal skelne mellem codepage(charset) og collating sequence.
Dansk og svensk (og andre) er indeholdt i latin1, men
_sorteringsrækkefølgen_ er forskellig.


> Dem er der mange af -
> kun een der hedder latin_general_cs. Har ikke tænkt på at prøve den,
> men det vil jeg.

Som nævnt kender jeg ikke så meget til mySQL, da mit metier er mere ovre i
'commercial strength' området, men du må på jagt om mySQL overhovedet
understøtter dine krav.

Kigger man på:
http://ific.uv.es/informatica/manuales/MySQL-4.1.1/manual_Charset.html

synes jeg mest nævnes Case Insensitive, men i min optik er case sensitivitet
noget der skulle have været aflivet for laang tid siden, da det kun
forårsager flere fejl end goder.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen kom med følgende:
> Birger Sørensen wrote:
>
>> Og det er latin1_bin, som iflg mine begreber, burde gøre rigtigt - mmen
>> som sltså sætter Å før Æ og Ø, men ellers placere dem efter Z.
>
> Nej, og ja.
>
> 'bin' er sikkert den binære værdi, hvor 'man' har lagt de danske tegn i
> forkert rækkefølge.
>
> Kig på:
> http://en.wikipedia.org/wiki/ISO/IEC_8859-1
> under _codepage_ layout.
>
> Her kan du se, at Å = 197,Æ=198 samt Ø=216.
>
> Dvs. _binær_ sortering vil give ÅÆØ i denne rækkefølge.
>
> Årsagen skal jeg lade være usagt, men 'gamle' folk husker tydeligt at ø/Ø
> var 'glemt' i de oprindelige codepages, og gav cent/Yen tegn.

Jow, jow - husker det, som var det i går.

>> Der er desuden et hav af andre, som jeg ikke rigtig har lyst til at
>> kaste mig ud i at forsøge med. Der er mange karaktersæt, men kun med
>> navn - ikke hvad de faktisk indeholder. Og eftersom siden de skal
>> bruges med, er iso-8859, bør det vel være latin1.
>
> Du skal skelne mellem codepage(charset) og collating sequence.
> Dansk og svensk (og andre) er indeholdt i latin1, men
> _sorteringsrækkefølgen_ er forskellig.

Og hvad er hvad, og hvori består forskellen?
Der er i øvrigt i MyPHPAdmin, ingen steder at sætte character set for
hverken tabellen eller data - kun collation.

En backup af tabellen ser sådan ud:
CREATE TABLE `ord_begreb` (
`begreb` varchar(125) character set latin1 collate latin1_bin NOT
NULL,
`anchor` varchar(50) character set latin1 collate latin1_bin NOT
NULL,
`sprog` varchar(15) character set latin1 collate latin1_bin NOT NULL
default ' ',
UNIQUE KEY `ord` (`begreb`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

Og ifht. ovenstående - at den binære rækkefølge i latin1 er forkert
ifht. det danske alfabet - er det underligt, at netop en BIN() sorterer
rigtigt...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Jow, jow - husker det, som var det i går.

He - ja sikke noget p*s.
Da vi lavede (PC baserede) ejendomsmæglersystemer i '80,erne, måtte vi købe
danske tegn som 'ekstraudstyr', da tegnene var 'brændt' i en prom.

>> Du skal skelne mellem codepage(charset) og collating sequence.
>> Dansk og svensk (og andre) er indeholdt i latin1, men
>> _sorteringsrækkefølgen_ er forskellig.
>
> Og hvad er hvad, og hvori består forskellen?

Codepage er mapningen mellem de binære værdier (eller codepoint) og den
tilhørende glyph, f.eks. iso-8859-1.

Collating sequende er den rækkefølge de skal vises i, og er ikke
nødvendigvis den samme som 'codepoint'-rækkefølgen.

Jeg har nævnt dansk og svensk som eksempel på forskellene, uagtet _codepage_
er det samme.

Se f.eks:
http://bongo-www.thefullwiki.org/Collating_sequence

Western-latin, som det vist hed, indeholder langt de fleste brugte
codepoint/glyph kombinationer, men _sorteringsrækkefølgen_ er forskellig.

Tænk også på Aalborg, som på dansk er sidestillet med Ålborg.

Dansk vtr. Svensk (citat fra ovenstående):
<quote>
In the Danish and Norwegian alphabets, the same extra vowels as in Swedish
(see below) are also present but in a *different* order..
</quote>

(fremhævning 'by me').

> Der er i øvrigt i MyPHPAdmin, ingen steder at sætte character set for
> hverken tabellen eller data - kun collation.

PHPAdmin er kun et interface, og behøver vel ikke at indeholde samtlige
varianter..?

Jeg foretrækker til enhver tid et almindeligt SQL interface, hvor man selv
kan udstede kommandoerne.

Det er også nemmere at dokumentere, da man kan copy/paste definitioner på
tværs af databaser (i det omfang de er standard compliant).

Hvad med at finde et GUI til mySQL?
http://www.google.com/search?q=mysql+windows+client&ie=UTF-8&oe=UTF-8

Måske er der noget der er bedre/lettere en PHPAdmin..?

--
Med venlig hilsen
Stig Johansen

---

Sorteringproblematikken...
Efter en backup og restore, bliver der så sorteret hulter til bulter,
og i hvert fald hverken efter det danske alfabet, eller noget
karaktersæt jeg kender....

Så løsningen med BIN(), er ikke anvendelig.

Til gengæld, er så alle attributter redefineret til utf8_bin, og der
sorteres efter utf8_danish_ci - hvilket i hvert fald efter de første
tests, ser ud til at gøre som forventet...

Jeg sorterer to steder:

SELECT anchor, over, forklaring FROM ord_forklar ORDER BY UPPER(over)
COLLATE utf8_danish_ci
og den komplicerede (som også kun giver det ønskede resultat delvist):
SELECT st1.anchor, st2.over, st2.sprog, st2.forklaring FROM (SELECT
anchor, begreb FROM ord_begreb) AS st1 JOIN (SELECT anchor, over,
sprog, forklaring FROM ord_forklar) AS st2 ON st2.anchor=st1.anchor
ORDER BY UPPER(st1.begreb) COLLATE utf8_danish_ci
og
SELECT begreb, sprog FROM ord_begreb WHERE anchor=? ORDER BY
UPPER(begreb) COLLATE utf8_danish_ci

Jeg er ikke sikker på at UPPER() så faktisk er nødvendig - men ellers
opfører det sig eksemplarisk - på dansk...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Jeg er ikke sikker på at UPPER() så faktisk er nødvendig - men ellers
> opfører det sig eksemplarisk - på dansk...

Hvis _ci står for Case Insensitive, kan jeg ikke rigtig se begrundelsen for
UPPER ;)

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen udtrykte præcist:
> Birger Sørensen wrote:
>
>> Jeg er ikke sikker på at UPPER() så faktisk er nødvendig - men ellers
>> opfører det sig eksemplarisk - på dansk...
>
> Hvis _ci står for Case Insensitive, kan jeg ikke rigtig se begrundelsen for
> UPPER ;)

Har også fjernet den, og det virker fortrinligt uden! :D

Noget med at "Nu virker det endelig!" - og når man har bokset i to uger
for at nå dertil, tager man eet skridt af gangen, efterfølgende.. :/

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Noget med at "Nu virker det endelig!" - og når man har bokset i to uger
> for at nå dertil, tager man eet skridt af gangen, efterfølgende.. :/

Jeg vil helst ikke komme med kommentarer om 'learning by failing'

(PS: nu er det ikke lige emnet, men det ærgrede mig sidste møde i
webdesigngruppen skulle blive i Fåborg.
Mit 1. møde var hyggeligt, men selv fra Odense var det en 'borgerkrig' at
komme hjem, så jeg kunne slet ikke overskue Fåborg).

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen sendte dette med sin computer:
> Birger Sørensen wrote:
>
>> Noget med at "Nu virker det endelig!" - og når man har bokset i to uger
>> for at nå dertil, tager man eet skridt af gangen, efterfølgende.. :/
>
> Jeg vil helst ikke komme med kommentarer om 'learning by failing'

:') Min foretrukne...
Syntes nu der mangler noget dokumentation omkring emnet. De ville måske
hjælpe på forståelsen. Måske også øge risikoen for succes...

> (PS: nu er det ikke lige emnet, men det ærgrede mig sidste møde i
> webdesigngruppen skulle blive i Fåborg.
> Mit 1. møde var hyggeligt, men selv fra Odense var det en 'borgerkrig' at
> komme hjem, så jeg kunne slet ikke overskue Fåborg).

Jeg var heller ikke med i Fåborg, og ved endnu ikke om jeg kan være med
i år.
Har familie i Foldby - så hvis, bliver forhåbentligt med udgangspunkt
derfra.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk