Mahlzeit.

Ich schreibe für steffenw weiter, da eigentlich ich das Problem habe und nicht er ;o).

Also das Problem ansich umfasst folgende Bereiche:

Ein MS-SQL Server kann UTF-8 Daten aufnehmen in n(text|varchar|date etc) Feldern. Er speichert die Daten intern aber nicht UTF-8 sonder UCS2 ab. FreeTDS gibt UTF-8 Daten beim Schreiben in die DB richtig weiter. Beim Auslesen veranlasst der Parameter CLIENT CHARSET = UTF-8 FreeTDS dazu die Daten aus der SQL Server DB nach UTF-8 zu encodieren obwohl sie bereits UTF-8 in der DB stehen. Resultat: zweifaches UTF-8 Encoding auf einen String -> nichts mehr lesbar.
Eine Überprüfung ist nicht möglich. Wenn Daten als z.B. ISO-8859-1 in der DB stehen, dann funktioniert der Parameter CLIENT CHARSET = UTF-8 zwar, kann den Originalstring aber nicht sauber nach UTF-8 encodieren.

Grundsätzlich ist mein Problem also erst mal FreeTDS. OpenLink ist evtl. eine Alternative, die allerdings Laufzeitprobleme aufgrund der ODBC Emulation unter Linux mit sich bringt.

Nun stelle ich mal die Frage in den Raum (ausser der Umstellung auf ein anderes Datenbanksystem): was kann ich noch machen um von Linux aus SO mit einem MS-SQL Server zu kommunizieren das ich sauber und ohne weiteres Encoding (in Perl oder seitens der DB bzw. eines Clients zwischen Perl und der DB) Daten verarbeiten kann.