MsSQL Kyrillisch in NVarChar

[Perlsau]

Hallo SQL-Spezialisten und -Wissende,

in einer Testtabelle sind Spalten mit NVarchar definiert, um UTF-8-codierte Strings aufnehmen zu können. Es liegen Daten mit u.a. tschechischen, französischen, spanischen, portugiesischen und russischen Inhalten vor. Bei allen außer bei den russischen funktioniert der Bulk-Insert via Microsoft SQL Server Management Studio einwandfrei. Bei den russischen fand ich heraus, daß ich den Strings ein N voranstellen muß, um zumindest in DB-Manager eine korrekte Darstellung der kyrillischen Zeichen zu erreichen. Leider stellt mir das DBGrid (TJvDBGrid, Jedi-Komponente) alle Zeichen außer Ziffern als Fragezeichen dar, was möglicherweise an den Ado-Komponenten liegen könnte:

[Bernhard Geyer]

NVarchar und UTF8-Coderierung zu kombinieren ist Blödsinn.
Du musst in nvarchars UTF-16 Codierte Strings speichern.

[Bernhard Geyer]

jetzt ja gerade gesehen das die Daten in der DB korrekt sind.
Fall du Pre-D2009 verwendest wird es mit 99% der Delphi-Komponenten nicht gehen.
Danach kommt es auf die Kompos an. Ist im Grid evtl. irgendwas mit UTF8 eingestellt (wurde teilweise besch***weise gemacht um in alten Delphi-Versionen irgendwas mit Codepages/Charset hin zu bekommen.

[Perlsau]

Zitat von Bernhard Geyer:

NVarchar und UTF8-Coderierung zu kombinieren ist Blödsinn.
Du musst in nvarchars UTF-16 Codierte Strings speichern.

Okay, das probiere ich gleich mal aus, sobald mein Test mit einer anderen DB (Firebird) durch ist. Da gibt's nämlich bereits beim Bulk-Insert Probleme mit den kyrillischen Zeichen: Error Code 104. Seltsamerweise werden die bulgarischen Daten, die ja ebenfalls kyrillische Zeichen enthalten, korrekt eingelesen und zumindest in IbExpert korrekt dargestellt.

Doch zurück zu UTF-16: Gehe ich richtig in der Annahme, daß ich die Stringliste mit dem Parameter Unicode laden muß?
Liste.LoadFromFile(Datei, TEncoding.Unicode); statt wie bisher mit
Liste.LoadFromFile(Datei, TEncoding.UTF8); Das wäre ja einfach

Zitat von Bernhard Geyer:

jetzt ja gerade gesehen das die Daten in der DB korrekt sind.

Ja, die russischen Daten lud ich bisher in MsSQL mit vorangestellten N ein.

Zitat von Bernhard Geyer:

Fall du Pre-D2009 verwendest wird es mit 99% der Delphi-Komponenten nicht gehen.

Ich verwende im Augenblick XE2 Architect an einem Kundenrechner, Zugriff über dbGo (Ado)

Zitat von Bernhard Geyer:

Danach kommt es auf die Kompos an. Ist im Grid evtl. irgendwas mit UTF8 eingestellt (wurde teilweise besch***weise gemacht um in alten Delphi-Versionen irgendwas mit Codepages/Charset hin zu bekommen.

Nein, im Grid hab ich absolut gar nichts verändert. Da gibt's meiner eben erfolgten Überprüfung nach auch kein entsprechendes Property ...

Ich lasse jetzt gerade mal via PSPad die vorangestellten Ns bei den in Firebird fehlerhaft eingelesenen SQL-Dateien entfernen (ist ja klar, daß Firebird damit nichts anfangen kann, dort gibt's eben kein NVarchar) und versuche dann noch einmal, die in Firebird zu inserten. Danach stelle ich in meiner Anwendung, die auf MsSQL zugreift, auf Unicode statt UTF8 als Parameter beim Einlesen der Stringliste um und erzeuge die SQL-Dateien neu (natürlich nur die problematischen mit RU als Ländercode). Mal sehen, ob das was bringt ...

[Bernhard Geyer]

Zitat von Perlsau:

Doch zurück zu UTF-16: Gehe ich richtig in der Annahme, daß ich die Stringliste mit dem Parameter Unicode laden muß?
Liste.LoadFromFile(Datei, TEncoding.Unicode); statt wie bisher mit
Liste.LoadFromFile(Datei, TEncoding.UTF8); Das wäre ja einfach

Man sollte eigentlich nix brauchen wenn die Datei einen BOM hat.
Dann sollte es klar sein wie die Datei Codiert ist.

[sx2008]

Zitat von Perlsau:

... und zumindest in IbExpert korrekt dargestellt.

Beim SQL Server ist das Microsoft SQL Server Management Studio die Referenzanwendung.
Nur wenn im Management Studio alles richtig angezeigt wird sind die Feldinhalte in Ordnung.

Ein anderes Tool wie z.B. IdExpert zu verwenden ist ein Risiko das man nicht eingehen sollte.
Das heisst jetzt nicht, dass IbExpert es nicht kann oder schlechter ist; es ist halt nur ein Risiko weil IbExpert möglicherweise einen UTF-8-codierten String in einem 16-Bit-nvarchar-Feld "richtig" anzeigt, obwohl das nicht sein dürfte.

[Perlsau]

Zitat von Bernhard Geyer:

Man sollte eigentlich nix brauchen wenn die Datei einen BOM hat. Dann sollte es klar sein wie die Datei Codiert ist.

Offenbar verfügen die Dateien nicht über eine entsprechende Kennung. Wenn ich es so mache, wie du mir empfohlen hast, werden im DB-Manager wieder nur Fragezeichen statt kyrillischer Zeichen dargestellt. Offensichtlich sind das keine UTF-16-Dateien. Keine Ahnung, wie ich UTF-16-SQL-Scripte mit Delphi erzeugen kann.

Mache ich das mit UTF8 und vorangestelltem N, werden die Zeichen im DB-Manager richtig dargestellt, jedoch nicht im DBGrid, da stehen wiederum nur Fragezeichen. Bin mal gespannt, wie das mit chinesichen Zeichen wäre, aber für China ist derzeit keine Datei verfügbar, und die japanische Datei enthält keine japanischen Zeichen.

In Firebird dagegen konnte ich alle UTF-8-kodierten SQL-Dateien problemlos einlesen, sie werden dort auch alle richtig dargestellt. Jetzt werd ich mal schnell eine Testanwendung schreiben, um zu sehen, ob ich wenigstens die Firebird-Daten korrekt darstellen kann.

Vielleicht sollte ich noch einmal versuchen, den Feldtypen in MsSQL wieder auf Varchar umzustellen und danach noch einmal einlesen. Aber ich glaube nicht, daß das funktioniert, das hatte ich ja am Anfang und danach hab ich die die entsprechenden Felder erstmal alle auf NVarchar gestellt.

Das Projekt muß nicht unbedingt auf MsSQL basieren. Firebird hätte zudem den Vorteil, daß man eine Embedded-Variante erstellen könnte. Die Firebird-DB ist nach dem Einlesen aller PLZ-Daten im unnormalisierten Zustand ca. 200 MB groß, das ist vertretbar, finde ich. Mein derzeitiger Kunde/Auftraggeber/Scheffe zog MsSQL vor, weil seine eigenen Projekte hauptsächlich darauf basieren und einer seiner Großkunden, dessen Kunden teilweise in "Ostblock-Ländern" sitzen, eben auch MsSQL einsetzt. Man kann aber auch problemlos zwei Datenbanken in einer Anwendung ansprechen, wenn ich mich nicht sehr irre. Am Ende sollte das Projekt eigentlich in verschiedenen Versionen bereitstehen. Mal sehen, vielleicht investiert mein Kunde ja auch was in entsprechende Komponenten, die eine korrekte Darstellung kyrillischer Zeichen gewährleisten. Ich mach ja erst mal nur die Recherche-Arbeit und das Ausprobieren und krieg dafür erstmal auch nichts (außer der Möglichkeit, mit besserer Hard- und Software arbeiten zu können) ... Wenn das befriedigend läuft, wird man weitersehen ...

[Perlsau]

Zitat von sx2008:

Zitat von Perlsau:

... und zumindest in IbExpert korrekt dargestellt.

Beim SQL Server ist das Microsoft SQL Server Management Studio die Referenzanwendung.
Nur wenn im Management Studio alles richtig angezeigt wird sind die Feldinhalte in Ordnung.

Ein anderes Tool wie z.B. IdExpert zu verwenden ist ein Risiko das man nicht eingehen sollte.
Das heisst jetzt nicht, dass IbExpert es nicht kann oder schlechter ist; es ist halt nur ein Risiko weil IbExpert möglicherweise einen UTF-8-codierten String in einem 16-Bit-nvarchar-Feld "richtig" anzeigt, obwohl das nicht sein dürfte.

Da hattest du mich falsch verstanden: Selbstverständlich verwende ich für das Einlesen von SQL-Scripts in MsSQL ausschließlich das Management Studio. Ich schrieb oben vom Einlesen der SQL-Scripts in Firebird, und dieser Versuch war erfolgreich: Firebird stellt zumindest in IbExpert die kyrillsichen Zeichen korrekt dar. Die entsprechenden Felder sind vom Typ UTF8.

[Perlsau]

Resultat meines Umbaus der Anwendung von MsSQL auf Firebird: Mit Firebird gibt's absolut keine Probleme bezüglich der Darstellung kyrillischer Zeichen in UFT-8-Feldern, weder in IbExpert noch im DBGrid in der Anwendung. Wenn's nach mir gegangen wäre, hätte ich gleich Firebird eingesetzt.