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
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.
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)
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 ...