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

[juergen]

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?

[haentschman]

Hallöle...8-)

Zitat:

Aber dann im Memo der DB eben nicht.

Was ist ein Memo der Datenbank? :gruebel:

[juergen]

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. :wink:
Der Datentyp des Feldes ist varbinary.

[haentschman]

Zitat:

Aber ich glaube du weißt was ich meinte

...nö leider nicht. :zwinker:

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? :gruebel:


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

[Uwe Raabe]

Wenn es ein TMemoField ist, dann wird der Text mit Hilfe der Funktion GetAnsiString ermittelt und in einen

Delphi-Quellcode:

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

Delphi-Quellcode:

Sender.TBytes

auf das passende Encoding loslässt und das Ergebnis in

Delphi-Quellcode:

Text

zurückgibst.

[himitsu]

Warum nicht TEXT, bzw. NTEXT als Datentyp?

https://learn.microsoft.com/en-us/sq...l-server-ver16

[Blup]

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.

[juergen]

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Ü',
'DE',
'Ãœ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???....

[juergen]

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!

[Redeemer]

Zitat:

Zitat von himitsu (Beitrag 1527746)

Warum nicht TEXT, bzw. NTEXT als Datentyp?

https://learn.microsoft.com/en-us/sq...l-server-ver16

Die sind seit 2008 tot und können vieles nicht, was nvarchar(max) und varchar(max) können.