Nee nee das passt schon. Ja e stimmt schon das der SQL Server nicht ohne weiteres eine UTF-8 Collation unterstützt (mit etwas C# Code wäre aber auch das machbar als user defined datatype ab SQL Server 2005).
Also im Gegensatz zu MySQL kennt der MS-SQL Server keine feld spezifischen Zeichensätze. Um UTF-8 oder sonstige UNICODE Strings abzuspeichern nimmt man "n"-Datentypen. In der Regel ist das dann das "ntext" Feld da es die meisten Bytes für Strings halten kann. Das UCS2 Format benutzt der SQL Server rein intern zur Speicherung jeglicher Daten (ausser Binary Datentypen). Es läuft so: Ich speichere einen UTF-8 String in ein ntext Feld im SQL Server. Der wandelt das intern für sich nach UCS2 ab, vermerkt aber dass das Original Encoding UTF-8 war. Wenn ich jetzt auf genau diesen Datensatz einen SELECT ausführe wandelt der SQL-Server meinen zuvor eingetragenen String wieder in das Eingabeformat - in diesem Fall UTF-8 - zurück.
Und obwohl der daraus resultierende String wieder so encodiert ist, wie ich ihn haben will, wandelt z.B. eben FreeTDS den String dann nochmal um, auch wenn kein Client Charset angegeben wird. - Kann natürlich auch sein, dass ich hier einfach einen massiven Denkfehler habe.