Immer wieder kommt das Problem hoch, dass UCS2-Daten im Client per ODBC nicht korrekt ankommen.

Hierzu sollte man folgendes wissen:

Zugriff mittels ADO-Objekten

Hier gibt es ja 2 Methoden:
a) ODBC-Zugriff mit dem MSDASQL-Treiber
b) OLEDB-Zugriff mit dem IBMDA400/IBMDASQL-Treiber

Das Problem besteht ausschließlich mit dem ODBC-Zugriff per MSDASQL, ein OLEDB-ODBC-Wrapper.
Dieser Treiber ist leider schon etwas älter und wurde nie mehr aktualisiert!

Hierzu muss ich noch kurz auf die ODBC-Spezifikation eingehen:
UCS2 wurde erst mit ODBC 3.x eingeführt.
Der MSDASQL meldet sich beim CA-ODBC-Treiber als ODBC 2.x-Anwendung an. Nun denkt der CA-Treiber also, dass der gar kein UCS2 kann.
Also werden alle UCS2-Daten automatisch in SBCS-Daten umgewandelt wobei es dann halt zu den bekannten Ersatzzeichen kommt.

Das Problem besteht beim Excel-Import eigentlich nicht, sondern nur beim MS-Query.
MS-Query arbeitet bei ODBC leider wieder nur im 2.x-Modus, in der Vorschau werden UCS2-Zeichen nicht angezeigt.
Desweiteren wird in der Anzeige auch kein Unicode-Font verwendet.

Führt nun Excel selber den Import aus, wird gar kein ADO verwendet sondern die ODBC-Funktion der DAO-Zugriffe.
DAO wird nur noch mit MS-Office ausgeliefert und ist nicht mehr Bestandteil des Windows!

DAO ist nun allerdings eine ODBC 3.x-Anwendung, so dass der CA-Treiber nun wieder UCS2-Zeichen empfängt und korrekt in die Zellen übernimmt.

Häufig wird dann im VBA-Code allerdings wieder mit ADO gearbeitet.
Hier muss man für UCS2 auf jeden Fall auf den IBMDASQL ausweichen wenn UCS2-Daten benötigt werden.
Dies gilt auch für MS-Access-Anwendungen, die häufig mit ADO arbeiten obwohl das DAO-Objektmodell in MS-Access ja vorhanden ist.

Bei UTF-8 (CCSID 1208) sowie UTF-16 (CCSID 1200) besteht dieses Problem nicht, da keine Zeichenumsetzung erfolgt und die Daten native so als SBCS-Daten in die Anwendung kommen.

Zugriff per DAO-Objekten

Hier bestehen keine Probleme mit dem ODBC-Treiber, da sich DAO ja als ODBC 3.x-Anwendung outet.

Zugriff per JDBC

Auch hier gibt es keine Probleme mit UCS2, da Java bei Strings grundsätzlich mit UCS2 arbeitet. Der JDBC-Treiber des Toolkits kann das alles.