Umlaute in WHERE-Klausel

[to-ka]

Hallo zusammen, ich hab schon viel gesucht und nichts für das obige Thema gefunden.

Anfänglich, ohne Charset Eintrag bekam ich die Umlaute als Fragezeichen, mit dem Eintrag "iso8859_1" wird nun alles richtig angezeigt.
"Müller" ist also "Müller" und nicht mehr "M?ller".
Alles fein dachte ich, bis ich zum ersten mal nach einem String mit Umlaut suchte.
Jetzt aber verzweifele ich an dem Select Statement, besser gesagt an der Where Klausel.

Code: Alles auswählen

WHERE Name LIKE '%Müller%' 

liefert keine Ergebnisse.

Code: Alles auswählen

WHERE Name LIKE '%M%ller%' 

liefert Ergebnisse, aber natürlich im Zweifel auch welche, die ich nicht haben will.

Den Select Befehl zuvor mittels UTF8ToAnsi zu konvertieren war auch nicht erfolgreich.

Verwendet wird SQL-Server 2017 (das ist eine bestehende Datenbank und daran kann man nichts zu ändern, da das eigentliche Verwaltungsprogramm nicht in meiner Hand liegt und ich nur einen Viewer für die schnelle Suche mache)
Zugriff über TSQLConnection.

Für jeden Tipp dankbar
Thomas

[sstvmaster]

Versuch mal die LConvEncoding in die Uses aufzunehmen und dort gibts dann folgende Funktionen:

- UTF8ToCP1252
- CP1252ToUTF8

oder
- ISO_8859_1ToUTF8
- UTF8ToISO_8859_1

Das sollte für Windows passen

[MmVisual]

Man kann die Texte nicht direkt in den SQL Befehl eingeben sondern per Parameter übergeben:

Code: Alles auswählen

Query1.SQL.Text := 'SELECT * FROM table WHERE Bezeichnung LIKE :Bez ';
Query1.ParamByName('Bez').AsString := '%Müller%';

Damit sollte die Datenbank Komponente automatisch die Codierung korrekt zum SQL Server senden.

Ansonsten nehme die Datenbank Komponente Zeos, die kann das.

[to-ka]

Super, das war schon die Lösung:

Versuch mal die LConvEncoding in die Uses aufzunehmen und dort gibts dann folgende Funktionen:

- UTF8ToCP1252
- CP1252ToUTF8

oder
- ISO_8859_1ToUTF8
- UTF8ToISO_8859_1

Das sollte für Windows passen

Ganz herzlichen Dank
Gruß
Thomas

[to-ka]

Man kann die Texte nicht direkt in den SQL Befehl eingeben sondern per Parameter übergeben:

Code: Alles auswählen

Query1.SQL.Text := 'SELECT * FROM table WHERE Bezeichnung LIKE :Bez ';
Query1.ParamByName('Bez').AsString := '%Müller%';

Damit sollte die Datenbank Komponente automatisch die Codierung korrekt zum SQL Server senden.

Ansonsten nehme die Datenbank Komponente Zeos, die kann das.

Danke für den Hinweis, werd ich auch mal ausprobieren. Das mit den Parametern muss ich mir mal genauer ansehen, bisher hab ich mir immer das SQL Statement komplett vorher zusammengebaut. Aktuell hat mir der Tipp mit der Unit zum Konvertieren schon geholfen. Ich bewege mich ja ausschließlich auf Windows Rechnern.

[MmVisual]

Das hat mit "Windows Rechnern" und "Ausschließlich" nichts zu tun. Es kommt darauf an mit welcher Codepage/Codierung der SQL Server läuft, Dazu kommt noch dass man den MS SQL Server auch unter Linux laufen lassen kann.
Daher: Der String muss prinzipiell und immer korrekt gewandelt werden.

[Winni]

Hi!

Oder Du machst das wie die Sparkassen-Software.

Die liefert auf den Kontoauszügen von Frau Müller seit Jahren:

M ller

Grüße
Winni

[af0815]

Das hat mit "Windows Rechnern" und "Ausschließlich" nichts zu tun. Es kommt darauf an mit welcher Codepage/Codierung der SQL Server läuft, Dazu kommt noch dass man den MS SQL Server auch unter Linux laufen lassen kann.
Daher: Der String muss prinzipiell und immer korrekt gewandelt werden.

Ich kann aus Erfahrung sagen, das Micro$oft da sehr konsequent ist. Egal ob der Server unter Ubuntu oder Windows läuft, das ist immer dasselbe. Man kann es von Außen fast nicht feststellen Na ja bei den Backuppfaden sehe ich es sofort

Die Codepage hängt auch stark davon ab, was man für lokale Einstellungen der Server hat. Chinesisch (Mandarin) und Ungarisch sind schon herausfordernd. Da muss man schon in Scipts die Collation beachten.

[six1]

Hi!

Oder Du machst das wie die Sparkassen-Software.

Die liefert auf den Kontoauszügen von Frau Müller seit Jahren:

M ller

Grüße
Winni

Dann ist bei dieser SPK das "ü" kaputt
Mein Nachname hat auch einen Umlaut und bei meiner SPK funktioniert das "ö"

[Winni]

Dann ist bei dieser SPK das "ü" kaputt
Mein Nachname hat auch einen Umlaut und bei meiner SPK funktioniert das "ö"

Hi!

Ich rede von SFirm, die die Kontauszüge in einem Format aus den End-80ern von der Sparkasse holen. So wie die ankommen, ist da wirklich kein "ü" sondern ein Leerzeichen. Entweder geht das "ü" schon bei der Sparkasse verloren oder die Umwandlung von ANSI auf UTF8 ist fehlerhaft.

Vielleicht weil das ANSI-ü nur ein Byte braucht und das UTF8-ü zwei.
Dann müssten sie an der fragilen Uralt-Struktur rumschrauben, die überall Längen-Bytes enthält.

Winni (ohne 8. Bit im Namen)

[Socke]

Solange keiner auf die Idee kommt, Mobilfunkrufnummern als Fließkommzahl abzuspeichern. Oder habt ihr schon mal bei +4,912345678+E10 angerufen?

BTT: Die TMSSQLConnection setzt den Zeichensatz der Verbindung per Standard auf UTF-8, sofern in der Eigenschaft "CharSet" nichts anderes steht. Da das nach dem Login erfolgt, sollten im Benutzernamen und Kennwort keine Umlaute enthalten sein.

Wenn der Nachname also aus einer LCL-Eingabe kommt und dann per Parameter übergeben wird, sollte das eigentlich passen.
Wenn du die Eingabe fest im Programm kodiert hast, könnte dir der Compiler ein Bein stellen, da er ggf. von einer anderen Kodierung deines Quelltextes ausgeht.

[PascalDragon]

Solange keiner auf die Idee kommt, Mobilfunkrufnummern als Fließkommzahl abzuspeichern. Oder habt ihr schon mal bei +4,912345678+E10 angerufen?

Das hatte ich tatsächlich schon mal. Ich hatte meine Handynummer bei 'nem Adressformular als +171… angegeben und auf dem Ausdruck auf dem Versandlabel stand dann +1,71…+Exx

[Winni]

Das hatte ich tatsächlich schon mal. Ich hatte meine Handynummer bei 'nem Adressformular als +171… angegeben und auf dem Ausdruck auf dem Versandlabel stand dann +1,71…+Exx

Hi!

Dass ist ja cooler Mist! Da hätten sie lieber ein Int64 nehmen sollen. Da gehen 19 Ziffern rein - im internationalen Betrieb sind maximal 15 Telefon-Ziffern erlaubt.

Aber nicht immer sind Integer der ideale Typ für Zahlen:
Es sei an die Umstellung von 4telliger auf 5stellige PLZ Anfang der 90er erinnert:

Die Deppen von der Post führten für Dunkeldeutschland die führende Null ein. Heftiges Geschnitze an den Datenbanken. Die einen stellten auf String um. Und die anderen schrieben sich eine Routine, die für ein Integer immer 5 Ziffern ausspuckte - auch wenn es führende Nullen gab .

Und das alles, weil im Postministerium (!!!) überbezahlte Beamte mit unterbeleuchteten Gehirnen das Sagen hatten .

Winni

[MmVisual]

Darüber lässt sich streiten wer mehr unterbelichtet war, derjenige der die Datenbank designt hat oder der Beamte der den Datenbankdesignern eine Schnittchen schlagen wollte.
Bei ausländischen PLZ gibt es durchaus Zusatzzeichen mit drin, z.B. 123-45

Bild1.jpg (38.67 KiB) 1507 mal betrachtet

[Winni]

Hi!

Seit 1964 sind die Postleitzahlen in D rein numerisch, bis 1992 4stellig, danach 5stellig.
Davor gab es durchaus zb 23a und 23b.

Also war es für Westdeutschland korrekt, einen Integer zu nehmen, da keine führenden Nullen vor 1992 vorhanden waren.

Zu 4stelligen Zeiten wurden dann so weiter verteilt:

1000 Berlin 36

war Kreuzberg

Das System mit den 5stelligen Postleitzahlen ist in großen Teilen der EU übernommen worden. Dass Luxemburg nur 4 Stellen braucht, leuchtet ein.

Dass England aus ihrem bunten Gemisch aus Ziffern und Buchstaben nicht wegkommt ist wohl eher Vorsatz. Und für die maschinelle Lesbarkeit nicht förderlich.

Winni