AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken MsSQL Kyrillisch in NVarChar
Thema durchsuchen
Ansicht
Themen-Optionen

MsSQL Kyrillisch in NVarChar

Ein Thema von Perlsau · begonnen am 16. Mai 2013 · letzter Beitrag vom 17. Mai 2013
Antwort Antwort
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.232 Beiträge
 
Delphi 10.4 Sydney
 
#1

AW: MsSQL Kyrillisch in NVarChar

  Alt 16. Mai 2013, 20:42
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.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Perlsau
(Gast)

n/a Beiträge
 
#2

AW: MsSQL Kyrillisch in NVarChar

  Alt 16. Mai 2013, 21:35
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 ...
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:11 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz