> # Unicode and Non-Unicode ODBC Drivers

> The way in which a driver handles function calls from a Unicode application determines whether it is called a Unicode driver.

> ### Function Calls

> Instead of the standard ANSI SQL function calls, such as SQLConnect, Unicode applications employ W (wide) function calls, such as SQLConnectW. If the driver is a true Unicode driver, it can understand the "W" function calls and the Driver Manager can pass them through to the driver without conversion to ANSI. SequeLink Client for ODBC driver is a Unicode driver.

> Non-Unicode drivers cannot understand the W function calls; therefore, the Driver Manager must convert them to ANSI calls before sending them to the driver. The Driver Manager determines the ANSI encoding system to which it must convert by referring to a code page. On Windows, this reference is to the Active Code Page. On Linux/UNIX, it is to the IANAAppCodePage connection string attribute, part of the odbc.ini file.

> The following examples illustrate the conversion streams. The Driver Manager on Linux and UNIX prior to SequeLink Client 6.0 for ODBC assumes Unicode applications and Unicode drivers that use the same encoding (UTF-8). For SequeLink Client 6.0 for ODBC on Linux/UNIX, the Driver Manager determines the type of Unicode encoding of both the application and the driver, and performs conversions when the application and driver each use different types of encoding. This determination is made by checking two ODBC Environment Attributes: SQL_ATTR_APP_UNICODE_TYPE and SQL_ATTR_DRIVER_UNICODE_TYPE.

> #### Unicode Application with the SequeLink ODBC Driver

> An operation involving a Unicode application and the SequeLink Unicode driver is more efficient because no function conversion is involved. If the application and the driver use different types of encoding, there is some conversion overhead.

> ##### Windows

> 1. The Unicode application sends UCS-2 or UTF-16 function calls to the Driver Manager.
> 2. The Driver Manager does not have to convert the UCS-2 or UTF-16 function calls to ANSI. It passes the Unicode function call to the SequeLink driver.
> 3. The driver returns UCS-2 or UTF-16 argument values to the Driver Manager.
> 4. The Driver Manager returns UCS-2 or UTF-16 function calls to the application.

> ##### Linix/UNIX: SequeLink® Client 5.5 for ODBC

> 1. The Unicode application sends UTF-8 function calls to the Driver Manager.
> 2. The Driver Manager does not have to convert the UTF-8 function calls to ANSI. It passes the Unicode function call to the SequeLink for ODBC driver.
> 3. The driver returns UTF-8 argument values to the Driver Manager.
> 4. The Driver Manager returns UTF-8 function calls to the application.

> ##### Linux/UNIX: SequeLink® Client 6.0 for ODBC

> 1. The Unicode application sends function calls to the Driver Manager. The Driver Manager expects these function calls to be UTF-8 or UTF-16 based on the value of the SQL_ATTR_APP_UNICODE_TYPE attribute.
> 2. The Driver Manager passes the Unicode function call to the SequeLink for ODBC driver. The Driver Manager must perform function call conversions if the SQL_ATTR_APP_UNICODE_TYPE is different from SQL_ATTR_DRIVER_UNICODE_TYPE.
> 3. The driver returns argument values to the Driver Manager. Whether these are UTF-8 or UTF-16 argument values is based on the value of the SQL_ATTR_DRIVER_UNICODE_TYPE attribute.
> 4. The Driver Manager returns appropriate function calls to the application, based on the SQL_ATTR_DRIVER_UNICODE_TYPE attribute. The Driver Manager must perform function call conversions if the SQL_ATTR_APP_UNICODE_TYPE is different from SQL_ATTR_DRIVER_UNICODE_TYPE.

> #### Non-Unicode Application with the SequeLink® ODBC Driver

> An operation involving a non-Unicode application and the SequeLink Unicode driver incurs some overhead because function conversion is involved.

> ##### Windows

> 1. The non-Unicode application sends ANSI function calls to the Driver Manager.
> 2. The Driver Manager converts the ANSI function calls to UCS-2/UTF-16. It passes the Unicode function calls with UCS-2/UTF-16 argument values to the SequeLink for ODBC driver.
> 3. The SequeLink driver returns UCS-2/UTF-16 argument values to the Driver Manager.
> 4. The Driver Manager converts the UCS-2/UTF-16 argument values to ANSI and returns these argument values to the application.

> ##### Linux/UNIX: SequeLink® Client for ODBC 5.5

> 1. The non-Unicode application sends ANSI function calls to the Driver Manager.
> 2. The Driver Manager converts the ANSI function calls to UTF-8. It passes the Unicode function calls with UTF-8 argument values to the SequeLink for ODBC driver.
> 3. The SequeLink ODBC driver returns UTF-8 argument values to the Driver Manager.
> 4. The Driver Manager converts the UTF-8 argument values to ANSI and returns them to the application.

> ##### Linux/UNIX: SequeLink® Client for ODBC 6.0

> 1. The non-Unicode application sends ANSI function calls to the Driver Manager. The Driver Manager expects these function calls to be UTF-8 or UTF-16 based on the value of the SQL_ATTR_APP_UNICODE_TYPE attribute. Because non-Unicode applications will not set this attribute, the default of UTF-8 is used for the conversion.
> 2. The Driver Manager converts the ANSI function calls to UTF-8. It passes the Unicode function calls with UTF-8 argument values to the SequeLink ODBC driver.
> 3. The SequeLink for ODBC driver returns argument values to the Driver Manager. The value of the SQL_ATTR_APP_UNICODE_TYPE attribute determines whether these argument values are UTF-8 or UTF-16.
> 4. The Driver Manager converts the UTF-8 or UTF-16 argument values to ANSI and returns them to the application.

> ### Data

> ODBC C data types are used to indicate the type of C buffers that store data in the application. This is in contrast to SQL data types, which are mapped to native database types to store data in a database (data source). ANSI applications bind to the C data type SQL_C_CHAR and expect to receive information bound in the same way. Similarly, Unicode applications bind to the C data type SQL_C_WCHAR (wide data type) and expect to receive information bound in the same way. Any ODBC 3.5 compliant driver must be capable of supporting SQL_C_CHAR and SQL_C_WCHAR so that it can return data to both ANSI and Unicode applications.

> When the driver communicates with the database, it must use ODBC SQL data types, such as SQL_CHAR and SQL_WCHAR, that map to native database types. In the case of ANSI data and an ANSI database, the driver receives data bound to SQL_C_CHAR and passes it to the database as SQL_CHAR. The same is true of SQL_C_WCHAR and SQL_WCHAR in the case of Unicode data and a Unicode database.

> When data from the application and the data stored in the database differ in format, for example, ANSI application data and Unicode database data, then conversions must be performed. The driver cannot receive SQL_C_CHAR data and pass it to a Unicode database that expects to receive a SQL_WCHAR data type. The driver or the Driver Manager must, therefore, be capable of converting SQL_C_CHAR to SQL_WCHAR, and vice versa.

> The simplest cases of data communication are when the application, the driver, and the database are all of the same type and encoding, ANSI to ANSI to ANSI or Unicode to Unicode to Unicode. There is no data conversion involved in these instances.

> When there is a difference in types of data, it must be converted from one type to another at the driver or Driver Manager level, which involves additional overhead.

> The Unicode SequeLink driver, NOT the Driver Manager, converts SQL_C_CHAR (ANSI) data to SQL_WCHAR (Unicode) data, and vice versa, as well as SQL_C_WCHAR (Unicode) data to SQL_CHAR (ANSI) data, and vice versa.

> The driver must use client code page information (Active Code Page on Windows, IANAAppCodePage attribute on Linux/UNIX) to determine which ANSI codepage to use for the conversions.