AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken MSSQL+FireDAC: Umlaute im SQL Statement gehen "verloren"
Thema durchsuchen
Ansicht
Themen-Optionen

MSSQL+FireDAC: Umlaute im SQL Statement gehen "verloren"

Ein Thema von juergen · begonnen am 5. Okt 2023 · letzter Beitrag vom 8. Okt 2023
Antwort Antwort
Benutzerbild von juergen
juergen

Registriert seit: 10. Jan 2005
Ort: Bönen
1.174 Beiträge
 
Delphi 11 Alexandria
 
#1

MSSQL+FireDAC: Umlaute im SQL Statement gehen "verloren"

  Alt 5. Okt 2023, 12:42
Datenbank: MSSQL • Version: 2019 • Zugriff über: FireDAC
Hallo zusammen,

ich habe momentan das Phänomen, dass in einem SQL-Statement, welches ich in Delphi zusammenstelle und dann an die FDQuery.SQL.Text übergebe, dann im Memo der Datenbank keine Umlaute ankommen sondern seltsame Zeichen. Das tritt bei mir lokal nicht auf, aber auf einem englischen Server. Bei mir und auf dem engl. Server steht die Collation der Datenbank auf "Latin1_General_BIN2".

Wenn ich das SQL-Statement der FDQuery als Text sichere, stehen dort noch die Umlaute drin... Aber dann im Memo der DB eben nicht.
Ich konnte jetzt keine Eigenschaften an der FDConnection oder FDQuery finden, die Einfluss auf das Encoding(?) haben könnten.

Hat hier jemand eine Idee woran das liegen könnte?
Jürgen
Indes sie forschten, röntgten, filmten, funkten, entstand von selbst die köstlichste Erfindung: der Umweg als die kürzeste Verbindung zwischen zwei Punkten. (Erich Kästner)
  Mit Zitat antworten Zitat
Benutzerbild von haentschman
haentschman
Online

Registriert seit: 24. Okt 2006
Ort: Seifhennersdorf / Sachsen
5.388 Beiträge
 
Delphi 12 Athens
 
#2

AW: MSSQL+FireDAC: Umlaute im SQL Statement gehen "verloren"

  Alt 5. Okt 2023, 12:57
Hallöle...
Zitat:
Aber dann im Memo der DB eben nicht.
Was ist ein Memo der Datenbank?
  Mit Zitat antworten Zitat
Benutzerbild von juergen
juergen

Registriert seit: 10. Jan 2005
Ort: Bönen
1.174 Beiträge
 
Delphi 11 Alexandria
 
#3

AW: MSSQL+FireDAC: Umlaute im SQL Statement gehen "verloren"

  Alt 5. Okt 2023, 13:05
Ok, das Memo ist natürlich nicht in der Datenbank, sondern das Control DBMemo zur Anzeige in der Anwendung. Aber ich glaube du weißt was ich meinte.
Der Datentyp des Feldes ist varbinary.
Jürgen
Indes sie forschten, röntgten, filmten, funkten, entstand von selbst die köstlichste Erfindung: der Umweg als die kürzeste Verbindung zwischen zwei Punkten. (Erich Kästner)
  Mit Zitat antworten Zitat
Benutzerbild von haentschman
haentschman
Online

Registriert seit: 24. Okt 2006
Ort: Seifhennersdorf / Sachsen
5.388 Beiträge
 
Delphi 12 Athens
 
#4

AW: MSSQL+FireDAC: Umlaute im SQL Statement gehen "verloren"

  Alt 5. Okt 2023, 13:15
Zitat:
Aber ich glaube du weißt was ich meinte
...nö leider nicht.

FDQuery.SQL.Text ist was anderes als das Ergebnis der Abfrage im Memo der Anwendung. Ich hatte das "Memo" (Abfrageeditor) der FireDAC Query im Sinn...

Nachtrag:
Zitat:
sondern das Control DBMemo zur Anzeige
Ist das eine manuelle Eingabe des SQL zu Runtime? Aber dann DBMemo?


Stehen die Umlaute schon im SQL oder im Ergebnis? Zeige mal ein SQL.Text Beispiel...und das erwartete Ergebnis und das Falsche.

Geändert von haentschman ( 5. Okt 2023 um 13:27 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.453 Beiträge
 
Delphi 12 Athens
 
#5

AW: MSSQL+FireDAC: Umlaute im SQL Statement gehen "verloren"

  Alt 5. Okt 2023, 13:54
Wenn es ein TMemoField ist, dann wird der Text mit Hilfe der Funktion GetAnsiString ermittelt und in einen string . Damit ist das Ergebnis abhängig von der aktuellen CodePage des Systems.

Du kannst das Verhalten aber mit einem OnGetText Eventhandler selber bestimmen, in dem du dort direkt Sender.TBytes auf das passende Encoding loslässt und das Ergebnis in Text zurückgibst.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.071 Beiträge
 
Delphi 12 Athens
 
#6

AW: MSSQL+FireDAC: Umlaute im SQL Statement gehen "verloren"

  Alt 5. Okt 2023, 15:45
Warum nicht TEXT, bzw. NTEXT als Datentyp?

https://learn.microsoft.com/en-us/sq...l-server-ver16
Neuste Erkenntnis:
Seit Pos einen dritten Parameter hat,
wird PoSex im Delphi viel seltener praktiziert.
  Mit Zitat antworten Zitat
Blup

Registriert seit: 7. Aug 2008
Ort: Brandenburg
1.464 Beiträge
 
Delphi 12 Athens
 
#7

AW: MSSQL+FireDAC: Umlaute im SQL Statement gehen "verloren"

  Alt 5. Okt 2023, 16:17
Eventuell muss die Collation für dieses Feld im SQL beim schreiben und/oder lesen explizit mit angeben werden.
Eben weil es kein reines Text-Feld ist.
  Mit Zitat antworten Zitat
Benutzerbild von juergen
juergen

Registriert seit: 10. Jan 2005
Ort: Bönen
1.174 Beiträge
 
Delphi 11 Alexandria
 
#8

AW: MSSQL+FireDAC: Umlaute im SQL Statement gehen "verloren"

  Alt 5. Okt 2023, 21:39
So, nun hier weiter. Ich setze von einem Array of String die Elemente-Werte in das VarBinary-Feld der Tabelle.

Das ist das Ergebnis aus dem VarBinary-Feld der Tabelle.
Abgefragt im SSMS mit
Code:
SELECT CONVERT(VARCHAR(MAX), CONVERT(VARBINARY(MAX), <my_VarBinary-Feld>)) From <my_Table> WHERE ID = 8
Code:
[
'5F',
'AG',
'WÃ&#339;',
'DE',
'Ã&#339;A'
]
Wie man sieht hat das drittletzte und letzte Element anstelle WÜ und ÜA falsche Zeichen für das Ü.
Die Idee mit Collate direkt im SQL mitzugeben war gut, hatte aber leider nichts bewirkt. Ich hatte COLLATE "Latin1_General_CI_AS" auf das Feld angewendet.
Wenn ich FDQery.SQL.Savetofile('xxxxx.txt') ausgebe, stehen die beiden Ü's da richtig drin. Nach dem SavetoFile der FDQuery feuere ich direkt FDQuery.ExecSQL ab.

Leider verstehe ich den Ansatz den Uwe vorgeschlagen hat nicht.

Hat noch jemand eine Idee?

Nachtrag: Wenn ich das SQL-Statement aus der txt_Datei von FDQuery.SQL.SaveToFile() über das SSMS des engl. Servers abfeuere, stehen die richtigen Werte in dem Tabellenfeld???....
Jürgen
Indes sie forschten, röntgten, filmten, funkten, entstand von selbst die köstlichste Erfindung: der Umweg als die kürzeste Verbindung zwischen zwei Punkten. (Erich Kästner)

Geändert von juergen ( 5. Okt 2023 um 21:47 Uhr) Grund: Nachtrag
  Mit Zitat antworten Zitat
Benutzerbild von juergen
juergen

Registriert seit: 10. Jan 2005
Ort: Bönen
1.174 Beiträge
 
Delphi 11 Alexandria
 
#9

AW: MSSQL+FireDAC: Umlaute im SQL Statement gehen "verloren"

  Alt 8. Okt 2023, 14:00
Kurze Rückmeldung:
Das Problem lag ganz woanders...
Das eigentliche Problem lag an meinem Json-Reader, der das Array aus der Json-Datei ausliest. Der hatte *kein* Encoding vorgegeben! Dann verwendet der Json-Reader wohl TEncoding.Default! Und genau das wendet dann wohl die Codepage des Betriebssystems an.
Nachdem ich nun das TEncoding.UTF8 für den Json-Reader fest vorgebe, funktioniert auch alles.
Wieder an Erfahrung dazugewonnen und 1 weiteres graues Haar

Allen einen schöne Sonntag noch!
Jürgen
Indes sie forschten, röntgten, filmten, funkten, entstand von selbst die köstlichste Erfindung: der Umweg als die kürzeste Verbindung zwischen zwei Punkten. (Erich Kästner)
  Mit Zitat antworten Zitat
Redeemer

Registriert seit: 19. Jan 2009
Ort: Kirchlinteln (LK Verden)
1.053 Beiträge
 
Delphi 2009 Professional
 
#10

AW: MSSQL+FireDAC: Umlaute im SQL Statement gehen "verloren"

  Alt 8. Okt 2023, 22:22
Die sind seit 2008 tot und können vieles nicht, was nvarchar(max) und varchar(max) können.
Janni
2005 PE, 2009 PA, XE2 PA
  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 06:19 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz