SQL Server-Codepages und Sortierfolgen - sql-server, Sortierung

Gibt es in SQL Server eine Möglichkeit, zu bestimmen, was ein Zeichen in einer Codepage darstellen würde, ohne tatsächlich eine Testdatenbank für diese Sortierung zu erstellen?

Beispiel. Wenn ich eine Testdatenbank mit Kollatierung erstelle SQL_Ukrainian_CP1251_CS_AS und dann CHAR(255) es kehrt zurück я.

Wenn ich folgendes auf einer Datenbank mit probiere SQL_Latin1_General_CP1_CS_AS Sortierung jedoch

SELECT CHAR(255) COLLATE SQL_Ukrainian_CP1251_CS_AS

Es kehrt zurück y

SELECT CHAR(255)

Kehrt zurück ÿ es wird also offensichtlich zuerst über die Standardkollatierung der Datenbank nach dem nächsten Äquivalent zu dieser in der expliziten Kollatierung gesucht. Kann dies vermieden werden?

Antworten:

2 für die Antwort № 1

Während MS SQL sowohl Codepages als auch Unicode unterstütztunhandlich, es gibt keine Funktionen, um zwischen den beiden zu konvertieren, so dass herauszufinden, welches Zeichen durch einen Wert in einer anderen Codepage dargestellt wird, ein Schwein ist.

Es gibt zwei mögliche Methoden, mit denen ich Konvertierungen durchführen kann. Eine wird hier detailliert beschrieben http://www.codeguru.com/cpp/data/data-misc/values/article.php/c4571 und beinhaltet das Verschrauben eines benutzerdefinierten Konvertierungsprogramms in die Datenbank und dessen Verwendung für Konvertierungen.

Die andere besteht darin, eine DB-Tabelle zu erstellen, die aus besteht

[CodePage], [ANSI Value], [UnicodeValue]

Der Unicode-Wert wird entweder als int gespeichert, der das Unicode-Zeichen darstellt, das mit konvertiert werden soll nchar()oder der nchar selbst

Sie verwenden die Kollatierung SQL_Ukrainian_CP1251_CS_AS Dies ist die Codepage 1251 (CP1251 von der Mitte der Zeichenfolge aus). Die Übersetzungstabelle finden Sie hier http://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT

Es ist ein TSV, also sollten die Rohdaten nach dem Abschneiden der Oberseite ziemlich sauber importiert werden.

Persönlich würde ich mich mehr zu Letzterem als zu Ersterem neigen, insbesondere für einen Produktionsserver, da Ersteres zu Instabilität führen kann.

---

7 für die Antwort № 2

Eigentlich habe ich jetzt eine Antwort auf meine Frage gefunden. Ein bisschen klobig, aber macht der Job es sei denn, es gibt einen besseren Ausweg?

SET NOCOUNT ON;

CREATE TABLE #Collations
(
code TINYINT PRIMARY KEY
);

WITH E00(N) AS (SELECT 1 UNION ALL SELECT 1),   --2
E02(N) AS (SELECT 1 FROM E00 a, E00 b), --4
E04(N) AS (SELECT 1 FROM E02 a, E02 b), --16
E08(N) AS (SELECT 1 FROM E04 a, E04 b) --256
INSERT INTO #Collations
SELECT ROW_NUMBER() OVER (ORDER BY (SELECT 0)) - 1
FROM E08

DECLARE @AlterScript NVARCHAR(MAX) = ""

SELECT @AlterScript = @AlterScript + "
RAISERROR(""Processing" + name + """,0,1) WITH NOWAIT;
ALTER TABLE #Collations ADD " + name + " CHAR(1) COLLATE " + name + ";
EXEC(""UPDATE #Collations SET " + name + "=CAST(code AS BINARY(1))"");
EXEC(""UPDATE #Collations SET " + name + "=NULL WHERE ASCII(" + name + ") <> code"");
"
FROM   sys.fn_helpcollations()
WHERE  name LIKE "%CS_AS"
AND name NOT IN    /*Unicode Only Collations*/
( "Assamese_100_CS_AS", "Bengali_100_CS_AS",
"Divehi_90_CS_AS", "Divehi_100_CS_AS" ,
"Indic_General_90_CS_AS", "Indic_General_100_CS_AS",
"Khmer_100_CS_AS", "Lao_100_CS_AS",
"Maltese_100_CS_AS", "Maori_100_CS_AS",
"Nepali_100_CS_AS", "Pashto_100_CS_AS",
"Syriac_90_CS_AS", "Syriac_100_CS_AS",
"Tibetan_100_CS_AS" )


EXEC (@AlterScript)

SELECT * FROM #Collations

DROP TABLE #Collations

---