Die Datenbasis soll/muß auf einem MS SQL Server gehalten werden.

FreeTDS konvertiert, wobei es eigentlich nur nichts tun soll um die utf-8 Daten durchzulassen. Oder anders gesagt, das kann man nicht so konfigurieren.

Versuche mit openlink von perl aus funktionieren noch nicht - kein connect.

Hat jemand speziell mit utf-8 in Kombination mit MS SQL Server Erfahrungen?

Was für eine Version des FreeTDS verwendest du?
Du verwendest den OpenLink-ODBC-Treiber? Oder iODBC?
Oder wie?

Und mit welchem Perl-Modul greifts du auf die Datenbank zu?
DBD-ODBC? DBD-FreeTDS? DBD-Sybase. So ganz klar ist mir das nicht im Posting, sorry.

Welches Encoding bei der MSSQL-DB verwendet wird, stellst du bei der Erzeugung der DB ein.\n\n

<!--EDIT|GwenDragon|1156856242-->

FreeTDS Version: 0.63-1 (nightly build)

OpenLink-ODBC-Treiber:
zum Testen ja... genauer gesagt OpenLink incl. OpenLink SDK und dann DBD::ODBC

Und mit welchem Perl-Modul greifts du auf die Datenbank zu?
DBD-ODBC 0.45

DBD-FreeTDS?
ist mir unbekannt.

***

alternativ DBD::Sybase in Verbindung mit FreeTDS.
Hier bestehen aber in Verbindung mit FreeTDS diverse Encodingprobleme mit UTF-8 Daten und MS-SQL Server.

Welches Encoding hat denn die Datenbank?

Userguide freetds.conf
Parameter Client-Charset!?

FreeTDS Userguide Nonwestern lang

iconv im Unix-System wird verwendet, um eine Zeichensatzkonvertierung zu ermöglichen.

Umgebungsvariablen für ODBC gesetzt?\n\n

<!--EDIT|GwenDragon|1156857479-->

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.

Leifert der Server nun UCS2 oder UTF8?

Der Server liefert UTF-8. Er speichert seine Daten intern nur UCS2 ab.

Wenn im Perlskript geschrieben wird:

use utf8;
use DBD::ODBC;

dann müsste es doch gehen.

In freetds.conf und locales.conf darf dann wohl kein client-encoding charracterset stehen.

Aber mangels eines laufenden mssql derzeit vermutung, da ich kein FreeTDS am laufen habe.\n\n

<!--EDIT|GwenDragon|1156861687-->

Da gebe ich dir recht.
Das sollte eigentlich schon gehen. FreeTDS encoded dann aber leider trotzdem auch ohne Client Charset Angaben. Na gut dann werde ich da noch etwas weiter experimentieren.