Eigentlich sollte man meinen, dass mit Unicode diverse Probleme rund um das Thema Sonderzeichen endlich gegessen wären, aber leider durfte ich neulich erleben, dass dem nicht so ist.
Gegeben sei eine einfache Tabelle „test“ mit einer NVARCHAR(50)-Spalte „name“ und zwei Datensätzen: „Preussen“ und „Preußen“.
Eine ebenso einfache Abfrage
SELECT * FROM test WHERE name = 'Preussen'
liefert – wie man es erwartet – einen Treffer. Macht man aus Ihr ein Prepared Statement, dann sind es plötzlich zwei Treffer: „Preussen“ und „Preußen“.
Natürlich sucht man den Fehler nun erstmal im eigenen Code, findet aber nichts, also probiert man alternative JDBC-Treiber aus und… findet auch nichts, bis man das ganze zum Schluss im Management Studio versucht und auch dort das seltsame Verhalten reproduzieren kann. Erst ein expliziter CAST des Vergleichswertes nach VARCHAR behebt das Problem. Ob diese Lösung aber performanter ist als der Verzicht auf Prepared Statements habe ich noch nicht geprüft.
Pingback: daniel-weber.eu» Blog Archive » “Casting-Show” mit dem MS SQL Server – Teil 2