Zusätzliche Leerzeichen bei JDBC Abfrage

[dirty-mg]

Hallo liebes Forum,

meine Anwendung verbindet sich per JDBC zu einem MSSQL 2000 Server. Nun kommt es vor, dass bei einer Abfrage eines NVARCHAR Wertes zusätzliche Leerzeichen am Ende enthalten sind, die aber nicht in der DB gespeichert sind. Wenn ich es über eine ODBC Verbindung probiere, sind die Leerzeichen weg und alles funktioniert wie gewollt. Kann man das vielleicht im JDBC Treiber einstellen? Ich benutze übrigens den MS SQL 2000 JDBC Treiber.


Vielen Dank
Marcus

 

[maki]

Nimm jTDS: http://jtds.sourceforge.net/

IMHO besser als alles was von MS kommt.

 

[dirty-mg]

Hallo,

hab jetzt auch JTDS 1.2.2 ausprobiert. Der läuft allerdings besteht das Problem der zusätzlichen Leerzeichen weiterhin.

Hat jemand ne Idee?

mfg
Marcus

 

[bronks]

... hab jetzt auch JTDS 1.2.2 ausprobiert. Der läuft allerdings besteht das Problem der zusätzlichen Leerzeichen weiterhin.

Hat jemand ne Idee?

Da hilft nur String.trim()

 

[thE_29]

Die Frage ist halt ob da nicht wirklich Leerzeichen drinnen sind und ODBC das weg macht?

 

[dirty-mg]

wenn ich per SQL das Feld abfrage ==> LEN(feld) kommt 24 raus. Im Java ist der String dann 255 Zeichen lang ...

 

[FenchelT]

benutz statattdessen mal datalength()

 

[dirty-mg]

Hallo,

folgende Werte bekomme ich nun:

datalength(feld) = 510
LEN(feld) = 24

Das Feld hat den Datentyp NVARCHAR(255) NULL. Was genau gibt denn die Funktion datalength() an?

mfg
Marcus

 

[FenchelT]

Aus der Doku

LEN
Gibt die Anzahl der Zeichen im gegebenen Zeichenfolgenausdruck zurück (nicht die Anzahl an Bytes), wobei nachfolgende Leerzeichen ausgeschlossen werden.

DATALENGTH
Gibt die Anzahl von Bytes zurück, die zum Darstellen eines Ausdrucks verwendet werden.

Gib mal folgendes ein:

SELECT 'a'+ dein_feld + 'b'
FROm deine_tabelle

Dann siehst Du, wieviele Leerzeichen Du tatsaechlich in dem Feld hast

 

[dirty-mg]

Bei dieser Abfrage kommt raus: "aMeinWert ". Der String ist 256 Zeichen lang und das 'b' sehe ich leider nicht mehr. Sollte NVARCHAR nicht nur so viele Zeichen speichern, wie mein Wert lang ist? Kann man das irgendwie umgehen?

mfg
Marcus

 

[FenchelT]

Ist der Datentyp wirklich nvarchar() oder ist er nchar()?

Wie sind die Daten in das System gekommen? Von irgendwoher eingelesen, oder haendisch eingetippt?

 

[dirty-mg]

Anscheinend hat meine Anwendung die Leerzeichen eingefügt und die ODBC Bridge hat diese wieder entfernt. Somit ist es mir nicht aufgefallen. Hab jetzt meine Anwendung geändert. Komisch ist nur, dass der SQL Server bei der Abfrage "LEN(feld)" mir die Länge ohne die angehangenen Leerzeichen liefert.

 

[FenchelT]

Komisch ist nur, dass der SQL Server bei der Abfrage "LEN(feld)" mir die Länge ohne die angehangenen Leerzeichen liefert.

Hast Du meinen Doku Post gelesen?
Es ist nicht Aufgabe der len() Funktion dies zu tun. Dafuer gibt es datalength()

 

[dirty-mg]

Klar hab ich den gelesen. Hat mich nur gewundert, dass datalength() 510 ausgegeben hat obwohl das Feld doch max. 255 Zeichen speichern kann???

 

[SlaterB]

2 Byte pro char?

(keine Ahnung worum es sonst geht )

 

[dirty-mg]

2 Byte pro char? Ist das so oder vermutest du das nur?

 

[dirty-mg]

bin schon gespannt ...

 

[SlaterB]

vermute ich

 

[Gast]

510 / 255 = 2

 

[FenchelT]

vermute ich

richtig vermutet. Der Datentyp nvarchar benoetigt 2 Bytes pro Zeichen, da er Daten im Unicode Format ablegt.

 

[SlaterB]

zur Vermutung gehört auch noch, ob das für die Anzeige 510 überhaupt eine Rolle spielt

 

[dirty-mg]

Vielen Dank. Nun ist alles etwas klarer. Ich bekomme jetzt bsp. für LEN(feld) = 24 und für datalength(feld) = 48.

Bis demnächst

 

[FenchelT]

zur Vermutung gehört auch noch, ob das für die Anzeige 510 überhaupt eine Rolle spielt

Yap. Guck Dir dazu auf Seite 1 meinen zweiten Post an, da steht das ja schon erklaert.

:wink:

 

[SlaterB]

nicht von der Hand zu weisen

 

[dirty-mg]

Hab ich schon vorhin gelesen. mir war nur nicht klar, dass 2 Byte zum Speichern benötigt werden ;-) ich sag nur "rtfm" wa?

 

[thE_29]

Oho, da hat meine Antwort sogar gepasst
Diese elendige ODBC Bridge hat mich auch schon zur Weißglut gebracht