CharSet (CS) connection parameter

Anywhere

• NONE

  Specifying CharSet=NONE requests that the connection use the database CHAR character set encoding. This is the default behavior.

• character-set

  Specify the label for the character set encoding that you want to use.

DBLIB (ESQL,Perl, PHP, Python, Ruby), ODBC in ANSI mode: The local (client) operating system character set encoding.

ADO.NET, JDBC, ODBC in UNICODE mode, OLE DB: The database CHAR character set encoding.

JavaScript: The database NCHAR character set encoding.

If you supply a value for CharSet, the specified character set encoding is used for the current connection. Conversions are attempted from the database CHAR character set encoding to the specified connection character set encoding. The NCHAR character set encoding is not affected by this connection parameter.

ADO.NET, JDBC, and OLE DB are Unicode application programming interfaces so the CharSet setting is ignored.

The character set encoding label that you specify may be an alternate for the preferred label. In this case, the preferred label is reported by the CharSet connection property. For example, the following Interactive SQL command specifies the cp1251 character set encoding in the connection string.

dbisql -c "UID=DBA;PWD=passwd;CharSet=cp1251" "SELECT connection_property('CharSet')"

The result returned is:

connection_property('charset')
------------------------------
windows-1251

Some alternate character set encoding labels are not unique and should be avoided (for example, ibm-943_P15A-2003).

When unloading data, you can specify the character set using the CharSet connection parameter.

To avoid lossy character set conversions, setting the CharSet connection parameter is not recommended when using Unicode client APIs. Unicode client APIs include ADO.NET, OLE DB, and the SQL Anywhere JDBC driver. ODBC is also a Unicode client API when the wide (Unicode) functions are used.