MSSQL und String-Felder

[PASST]

Hallo allerseits,

ich habe ein seltsames Verhalten des MSSQL Server 2008 festgestellt.

Wenn ich eine Abfrage auf eine Tabelle ausführe, so werden mir alle Felder vom Datentyp String (bzw. Char oder NChar) mit maximaler Feldlänge angezeigt. D.h. das Resultat eines Feldes vom Typ NChar(20) wird als String angezeigt, der durch Leerzeichen auf 20 Zeichen ergänzt wird.

Wenn ich nun eine Abfrage auf ein solches Feld durchführe:

SQL-Code:

'WHERE Feld like ' + quotedstr(MeinText) + ' '

erhalte ich kein Ergebnis. Erst wenn ich 'MeinText' am Ende um Leerzeichen ergänze, so dass die maximale Feldlänge erreicht wird, erhalte ich ein Ergebnis.

Ist das normal so?

[WIng2005]

Versuch mal:

SQL-Code:

'WHERE Trim(Feld,'' '') like ' + quotedstr(MeinText) + ' '

bzw.

'WHERE Feld like %' + quotedstr(MeinText) + '% '

MFG
Steffen

[PASST]

Deine Variante würde mir zuviele Resultate ausgebe. Angenommen ich suche nach dem Eintrag mit dem String 'a'. So erhalte ich nach deiner Variante alle Ergebnisse wo 'a' im String enthalten ist.

Ich denke, ich muss es so machen:

SQL-Code:

WHERE RTRIM(Feld) like ' + quotedStr(MeinText) + ' '

T-SQL kennt nur LTRIM und RTRIM und nicht Trim.

[Bernhard Geyer]

Wieso nimmst du denn keine nvarchar Felder?

Und zusätzlich solltest du deine Abfragen auf prepared Statements umbauen.

[hazard999]

Mein Vorredner hatte fast recht:

'WHERE Feld like ' + quotedstr(MeinText + '%');

muss es heißen.

Sucht alle Records die mit MeinText anfangen

[nahpets]

Hallo,

soweit ich das mitbekommen habe, werden NChar mit Leerzeichen aufgefüllt, bis die passende Länge erreicht ist.

SQL-Code:

'WHERE Trim(Feld,'' '') like ' + quotedstr(MeinText) + ' '

wird nicht gehen, da das Leerzeichen ja an MeinText gehangen werden muss und nicht an das SQL. Besser wäre da wohl:

SQL-Code:

'WHERE Trim(Feld,'' '') like ' + quotedstr(MeinText + ' ')

wobei Du hier eventuell sogar 20 - Länge von MeinText Leerzeichen anfügen müsstest.
Bei

SQL-Code:

WHERE RTRIM(Feld) like ' + quotedStr(MeinText) + ' '

sollte dann aber

SQL-Code:

WHERE RTRIM(Feld) = ' + quotedStr(MeinText)

ausreichen.

[Bernhard Geyer]

Zitat:

Zitat von nahpets

soweit ich das mitbekommen habe, werden NChar mit Leerzeichen aufgefüllt, bis die passende Länge erreicht ist.

Deshalb sind es auch keine (N)varchars :-)

[hazard999]

Ich hoffe das da nicht allzuviele Records drin sind.

WHERE RTRIM(Feld) = ' + quotedStr(MeinText)

wird ein Table-Scan. Langsamer geht kaum mehr.

[WIng2005]

@nahpets: TRIM entfernt führende und nachfolgende Zeichen. Welches Zeichen, das bestimmst du mit dem entspr. Parameter.

SQL-Code:

'WHERE Trim(Feld,'' '') like ' + quotedstr(MeinText)

...bewirkt in dem Beispiel also nichts anderes als ein RTRIM(Feld).


MFG
Steffen

[nahpets]

Hallo,

Zitat:

Zitat von hazard999

Ich hoffe das da nicht allzuviele Records drin sind.

WHERE RTRIM(Feld) = ' + quotedStr(MeinText)

wird ein Table-Scan. Langsamer geht kaum mehr.

wäre dann ein

SQL-Code:

'WHERE Feld = ' + quotedStr(MeinText + '                                     ')

besser?

[WIng2005]

Ich denke wenn, dann eher via Format, oder?
Also:

'WHERE Feld = ' + quotedStr(Format('%.20s',['MeinText']))

MFG
Steffen

[PASST]

@nahpet

SQL-Code:

WHERE Feld like ' + quotedStr(MeinText) + ' '

Das Leerzeichen am Ende hat eigentlich nichts mit quotedstr(MeinText) zu tun. Das kann ignoriert werden.

@hazard999

Zitat:

Ich hoffe das da nicht allzuviele Records drin sind.
WHERE RTRIM(Feld) = ' + quotedStr(MeinText)
wird ein Table-Scan. Langsamer geht kaum mehr.

Da verlässt mich mein SQLServer-Verständnis. Warum ist das langsamer?

@Bernhard Geyer

Zitat:

Wieso nimmst du denn keine nvarchar Felder?

Aus Unwissen! Es gibt für mich keinen Grund auf (n)char zu bestehen. Wenn ich die Definition (n)varchar richtig verstehe, ist es genau das was ich brauche um dieses Problem zu lösen.

[Bernhard Geyer]

Zitat:

Zitat von PASST

@Bernhard Geyer

Zitat:

Wieso nimmst du denn keine nvarchar Felder?

Aus Unwissen! Es gibt für mich keinen Grund auf (n)char zu bestehen. Wenn ich die Definition (n)varchar richtig verstehe, ist es genau das was ich brauche um dieses Problem zu lösen.

Dann stell es um. Die alten Char-Felder sind m.E. primär für altkompatiblität gedacht für Anwendungen die nicht mit variablen längen zurecht kommen bzw. erhöhten Aufwand benötig (COBOL und Co. lassen Grüßen).

[shmia]

Entscheidungshilfe char oder varchar:
Haben die Strings grundsätzlich die gleiche Länge?
Hier einige Beispiele:
* Länderkürzel FR=Frankreich, DE=Deutschland
* Währung 3-stellig nach ISO 4217
* eine GUID hexadezimal codiert mit 32 Zeichen (verwendet man den nativen Datentyp bracht man nur 16 Bytes)
* ISBN-10 oder ISBN-13 (aber nur, wenn sicher ist, dass immer nur eine ISBN Länge verwendet wird)
=> dann Char verwenden
Hat das Stringfeld eine Länge von 1 ?
=> dann Char verwenden
In allen anderen Fällen varchar verwenden.

[Jürgen Thomas]

Ergänzung zu shmia's Aufstellung:

Ein Grenzfall ist ein Feld PLZ. Wenn es sich nur um deutsche Postleitzahlen handelt, passt CHAR(5). Wenn auch internationale Postcodes vorkommen, ist CHAR(10) denkbar, aber VARCHAR(10) besser.

BLZ immer CHAR(8), Konto wieder ein Grenzfall. Aber über kurz oder lang wird das sowieso durch IBAN ersetzt. Da dieses Feld immer zwischen 16 und 34 Stellen hat, dürfte VARCHAR besser sein als CHAR.

Jürgen