none
Falsche Sortierung von Umlauten RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    nachdem ich in  einem anderen Forum trotz freundlicher Unterstützung nicht weitergekommen bin, versuche ich es mal hier.

    Mein Problem ist, dass Kundendatensätze, die ich über ihren Nachnamen sortieren möchte nicht richtig sortiert werden, wenn die Nachnamen Umlaute enthalten.

    Bei meinen Tests habe ich bei 3(!) unterschiedliche physikalische SQL-Server (2 Instanzen von mir eingerichtet, 1 Instanz von einer "unbeteiligten" Person eingerichtet) immer das identische Ergebnis:

    - Ich habe jeweils eine neue Datenbank erstellt.
    - Tabelle hinzugefügt
    - Feld ID (=Identifikationsspalte) hinzugefügt
    - Feld Nachname hinzugefügt
    - Darauf geachtet, dass in der jeweiligen Datenbank als Sortierung Latin1_General_CI_AS eingestellt ist
    - Geprüft, ob im Feld Nachname als Sortierung "Datenbankstandard" eingestellt ist.
    - In die Tabelle die Nachnamen eingefügt.

    Folgendes SQL-Statement bringt dann bei allen 3 Servern das unten genannte (falsche) Ergebnis

    SELECT Nachname from Testtabelle order by Nachname collate Latin1_General_CI_AS;

    - Fobes
    - Forster
    - Förster
    - Fösges
    - Foshag (!!)
    - Föskus

    Ich bin am Ende meines "Latin"

    Vielen Dank für jede Unterstützung.

    Gernot


    Freitag, 10. August 2012 12:45
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    Hallo Gernot,

    grundsätzlich ist die alphabetische Sortierung doch richtig.

    Es sei den, Du möchtest es wie im Telefonbuch sortiert haben; die Vermutung liegt bei Nachnamen nahe. Dann musst Du einfach nur die Telefonbuch Collation verwenden, von der gibt es einige:

    DECLARE @tbl AS Table(Nachname varchar(20));

INSERT INTO @tbl VALUES('Fobes');
INSERT INTO @tbl VALUES('Forster');
INSERT INTO @tbl VALUES('Förster');
INSERT INTO @tbl VALUES('Fösges');
INSERT INTO @tbl VALUES('Foshag');
INSERT INTO @tbl VALUES('Föskus');

SELECT *
FROM @tbl
ORDER BY Nachname COLLATE Latin1_General_CI_AS;

SELECT *
FROM @tbl
ORDER BY Nachname COLLATE German_PhoneBook_CI_AS;

    Das liefert dann:

    Fobes
    Förster
    Fösges
    Föskus
    Forster
    Foshag

    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing


    Freitag, 10. August 2012 12:57
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Gernot,

    entschuldige, ich hatte Deinen letzten Beitrag im Vorgängerthread übersehen.

    Ich hatte damals zwar noch etwas "geforscht", aber kein wirklichen Grund dafür finden können.
    Die Ursache dürfte an den Dateien für den National-Languagesupport (wie schon verlinkt) liegen.
    Grober Verdacht: Da passen einige Dateien nicht.

    Auf welchen Betriebssystemen (XP, Vista, Windows 7?) sind die SQL Server (welche Version, SP) installiert worden?

    Um mögliche Unterschiede zu finden, verwende bitte mal als Datentyp VARCHAR (und nicht NVARCHAR)
    und für die COLLATE Klausel andere Sprachen, wie zu finden unter: Sortierungseinstellungen im Setup-Programm

    Möglich wäre z. B.  Czech_CI_AS (als osteuropäisch sollte eine andere Codedatei verwenden),
    oder Turkish_CI_AS (da Türkisch sonst gerne Probleme bereitet ;-)

    NACHTRAG:

    Olaf hat mich indirekt darauf aufmerksam gemacht, dass Du die Testdaten gewechselt hast.
    Foshag ist "richtig" einsortiert, denn "ö" => "oes" wird vor "os" sortiert.

    Der einzige relevante Unterschied war im vorherigen Thread der von Forster <==> Förster gewesen.
    Und Worte sind im Vergleich identisch bei CI_AI Sortierung, wie man sieht wenn man eine zweites Kriterium verwendet:

    DECLARE @daten TABLE (id int identity(1, 1), wort nvarchar(40) );
INSERT INTO @daten VALUES (N'Förster'), (N'Fösges'), (N'Föskus'), (N'Forster'), (N'Fobes'), (N'Foshag');

--SELECT wort AS CI_AS_ASC , id FROM @daten ORDER BY wort COLLATE Latin1_General_CI_AS, id ASC;
--SELECT wort AS CI_AS_DESC, id FROM @daten ORDER BY wort COLLATE Latin1_General_CI_AS, id DESC;

--SELECT wort AS PB_AI_ASC , id FROM @daten ORDER BY wort COLLATE German_PhoneBook_CI_AS, id ASC;
--SELECT wort AS PB_AI_DESC, id FROM @daten ORDER BY wort COLLATE German_PhoneBook_CI_AS, id DESC;

-- Forster == Förster (id wechselt)
SELECT wort AS CI_AI_ASC, id FROM @daten ORDER BY wort COLLATE Latin1_General_CI_AI, id ASC;
SELECT wort AS CI_AI_DESC, id FROM @daten ORDER BY wort COLLATE Latin1_General_CI_AI, id desc;

    was wiederum für eine angewendete CI_AI Sortierung bedeuten würde, dass das angezeigte Ergebnis
    "zufällig" wäre, je nachdem wie der Algorithmus die Eingangsdaten bei Gleichheit umsortiert (oder eben nicht).

    Womit dann kein "Fehler" sondern der "Zufall" über das Ergebnis entscheidet.

    Gruß Elmar


    Freitag, 10. August 2012 13:11
    |
    Beantworter
  • Question
    Anmelden
    1
    Anmelden

    Hallo Gernot,

    ich bekenne mich insofern schuldig, als ich den SQL Server ins Spiel gebracht habe ;-)
    Der Grund war, eine einfachere Möglichkeit zu haben, Zugriff auf unterschiedliche
    Sortiermöglichkeiten zu haben, die im SQL Server direkt eingebaut sind.

    Die Autocomplete Methoden verhalten sich, wie bereits geschrieben, entsprechend
    der Sortiereinstellungen - Systemsteuerung -> Region und Sprache bzw. Ländereinstellungen (XP).

    Wenn Du die Sortieroption "Telefonbuch" verwendest, kommt es nicht mehr zum "Ausblenden"
    bei "ö" und anderen Umlauten, da die Buchstaben dann einheitlich einsortiert werden.
    Voreingestellt ist das allerdings nicht, so dass man die Systeme anpassen muss.

    Insofern hat der Anwender immerhin die Wahl, wenn es ihn ebenso stört.

    Gruß Elmar

    Montag, 13. August 2012 09:53
    |
    Beantworter

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Hallo Gernot,

    grundsätzlich ist die alphabetische Sortierung doch richtig.

    Es sei den, Du möchtest es wie im Telefonbuch sortiert haben; die Vermutung liegt bei Nachnamen nahe. Dann musst Du einfach nur die Telefonbuch Collation verwenden, von der gibt es einige:

    DECLARE @tbl AS Table(Nachname varchar(20));

INSERT INTO @tbl VALUES('Fobes');
INSERT INTO @tbl VALUES('Forster');
INSERT INTO @tbl VALUES('Förster');
INSERT INTO @tbl VALUES('Fösges');
INSERT INTO @tbl VALUES('Foshag');
INSERT INTO @tbl VALUES('Föskus');

SELECT *
FROM @tbl
ORDER BY Nachname COLLATE Latin1_General_CI_AS;

SELECT *
FROM @tbl
ORDER BY Nachname COLLATE German_PhoneBook_CI_AS;

    Das liefert dann:

    Fobes
    Förster
    Fösges
    Föskus
    Forster
    Foshag

    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing


    Freitag, 10. August 2012 12:57
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Gernot,

    entschuldige, ich hatte Deinen letzten Beitrag im Vorgängerthread übersehen.

    Ich hatte damals zwar noch etwas "geforscht", aber kein wirklichen Grund dafür finden können.
    Die Ursache dürfte an den Dateien für den National-Languagesupport (wie schon verlinkt) liegen.
    Grober Verdacht: Da passen einige Dateien nicht.

    Auf welchen Betriebssystemen (XP, Vista, Windows 7?) sind die SQL Server (welche Version, SP) installiert worden?

    Um mögliche Unterschiede zu finden, verwende bitte mal als Datentyp VARCHAR (und nicht NVARCHAR)
    und für die COLLATE Klausel andere Sprachen, wie zu finden unter: Sortierungseinstellungen im Setup-Programm

    Möglich wäre z. B.  Czech_CI_AS (als osteuropäisch sollte eine andere Codedatei verwenden),
    oder Turkish_CI_AS (da Türkisch sonst gerne Probleme bereitet ;-)

    NACHTRAG:

    Olaf hat mich indirekt darauf aufmerksam gemacht, dass Du die Testdaten gewechselt hast.
    Foshag ist "richtig" einsortiert, denn "ö" => "oes" wird vor "os" sortiert.

    Der einzige relevante Unterschied war im vorherigen Thread der von Forster <==> Förster gewesen.
    Und Worte sind im Vergleich identisch bei CI_AI Sortierung, wie man sieht wenn man eine zweites Kriterium verwendet:

    DECLARE @daten TABLE (id int identity(1, 1), wort nvarchar(40) );
INSERT INTO @daten VALUES (N'Förster'), (N'Fösges'), (N'Föskus'), (N'Forster'), (N'Fobes'), (N'Foshag');

--SELECT wort AS CI_AS_ASC , id FROM @daten ORDER BY wort COLLATE Latin1_General_CI_AS, id ASC;
--SELECT wort AS CI_AS_DESC, id FROM @daten ORDER BY wort COLLATE Latin1_General_CI_AS, id DESC;

--SELECT wort AS PB_AI_ASC , id FROM @daten ORDER BY wort COLLATE German_PhoneBook_CI_AS, id ASC;
--SELECT wort AS PB_AI_DESC, id FROM @daten ORDER BY wort COLLATE German_PhoneBook_CI_AS, id DESC;

-- Forster == Förster (id wechselt)
SELECT wort AS CI_AI_ASC, id FROM @daten ORDER BY wort COLLATE Latin1_General_CI_AI, id ASC;
SELECT wort AS CI_AI_DESC, id FROM @daten ORDER BY wort COLLATE Latin1_General_CI_AI, id desc;

    was wiederum für eine angewendete CI_AI Sortierung bedeuten würde, dass das angezeigte Ergebnis
    "zufällig" wäre, je nachdem wie der Algorithmus die Eingangsdaten bei Gleichheit umsortiert (oder eben nicht).

    Womit dann kein "Fehler" sondern der "Zufall" über das Ergebnis entscheidet.

    Gruß Elmar


    Freitag, 10. August 2012 13:11
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hallo Elmar,

    nachdem ich am Wochenende Zeit hatte nochmal über alles nachzudenken, hast Du natürlich recht, dass die Sortierung prinzipiell stimmt.

    Mein Ausgangsproblem (im im Vorgängerthread beschrieben) ist ja folgendes:

    <snip>

    Ausgangssituation:

    Textbox mit Autocompletefunktion (AutoCompleteCustomSource; Modus: suggest)
    Alles funktioniert auch einwandfrei, bis auf folgendes Phänomen:

    Ich "adde" folgende Namen zur CustomSource:

    [...Haufen von Namen...]
    Förster
    Forster
    Fösges
    Föskus
    [...Haufen von Namen...]

    Wenn ich nun ein "f" eintippe, kommen alle Nachnamen mit dem Anfangsbuchstaben "f" in der Liste.
    Wenn ich nun ein "fö" eintippe, kommt nur(!) noch "Förster".
    Wenn ich nun ein "fös" eintippe, kommt nur(!) noch "Fösges".

    Das Problem ist bei den unterschiedlichsten Textboxen nachzuvollziehen (Neu erstellt, neue Textapplikation etc).

    Das Problem liegt scheinbar bei dem Namen "Forster" (insbesondere, dass dieser "zwischen" den Umlauten liegt).

    Füge ich den Forster nicht zu der Auflistung hinzu, verhält sich das Autocomplete wie erwartet.
    <snip>

    Du hast mich dann freundlicherweise auf die Idee gebracht, dass eventuell falsch sortiert werden würde; nach meinen weiteren Versuche, hat dies aber offensichtlich nichts mit dem SQL-Server zu tun. Auch wenn ich die Autocompletesource manuell fülle, habe ich obiges Problem.

    Damit dürfte ich zwar jetzt in diesem Forum "Off-Topic" sein,.... vielleicht gibt es ja doch eine Lösung auch hier.

    Danke

    Gernot

    Montag, 13. August 2012 08:29
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Gernot,

    ich bekenne mich insofern schuldig, als ich den SQL Server ins Spiel gebracht habe ;-)
    Der Grund war, eine einfachere Möglichkeit zu haben, Zugriff auf unterschiedliche
    Sortiermöglichkeiten zu haben, die im SQL Server direkt eingebaut sind.

    Die Autocomplete Methoden verhalten sich, wie bereits geschrieben, entsprechend
    der Sortiereinstellungen - Systemsteuerung -> Region und Sprache bzw. Ländereinstellungen (XP).

    Wenn Du die Sortieroption "Telefonbuch" verwendest, kommt es nicht mehr zum "Ausblenden"
    bei "ö" und anderen Umlauten, da die Buchstaben dann einheitlich einsortiert werden.
    Voreingestellt ist das allerdings nicht, so dass man die Systeme anpassen muss.

    Insofern hat der Anwender immerhin die Wahl, wenn es ihn ebenso stört.

    Gruß Elmar

    Montag, 13. August 2012 09:53
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hallo Gernot Pfeifer,

    Ich gehe davon aus, dass die Antworent Dir weitergeholfen haben.
    Solltest Du noch "Rückfragen" dazu haben, so gib uns bitte Bescheid.

    Grüße,
    Robert

    Robert Breitenhofer, MICROSOFT  Twitter Facebook
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Freitag, 17. August 2012 09:55
    |
    Moderator