Fuerchau
18-10-13, 17:37
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.
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.