| Localization / Application locale | |
This section describes the settings defining the locale for the database client. Each database software has its own client character set configuration.
You must properly configure the database client locale in order to send/receive data to the database server, according to the locale used by your application. Both database client locale and application locale settings must match (you cannot have a database client locale in Japanese and a runtime locale in Chinese).
Here is the list of environment variables defining the locale used by the application, for each supported database client:
| Database Client | Settings |
|---|---|
| Oracle database server | The client locale settings can be set with environment variables like NLS_LANG, or after connection, with the ALTER SESSION instruction. By default, the client locale is set from the database server locale. |
| IBM® Informix® | The client locale is defined by the CLIENT_LOCALE environment variable. For backward compatibility, if CLIENT_LOCALE is not defined, other settings are used if defined (DBDATE / DBTIME / GL_DATE / GL_DATETIME, as well as standard LC_* variables). |
| IBM DB2® | The client locale is defined by the DB2CODEPAGE profile variable. You cat set this variable with the db2set command. However, you usually do not need to set this variable: If DB2CODEPAGE is not set, DB2 uses the operating system code page on Windows™ and the LANG/LC_ALL locate setting on UNIX™. When using a UTF-8 locale on Windows, DB2CODEPAGE must be set to 1208. |
| Microsoft™ SQL Server | For MSV and SNC drivers on Windows platforms, the database client locale is defined by the language
settings for non-Unicode applications. The current ANSI code page (ACP) is used by the SQL Server
client and the Genero runtime system. When using the FTM (FreeTDS) driver, the client character set is defined by the client charset parameter in freetds.conf or with the ClientCharset parameter in the DSN of the odbc.ini file. When using the ESM (EasySoft) driver, the client character set is defined by the Client_CSet parameter in the DSN of the odbc.ini file. When using CHAR/VARCHAR types in the database and when the database collation is different from the client locale, you must also set the Server_CSet parameter to an iconv name corresponding to the database collation. For example, if Client_CSet=BIG5 and the db collation is Chinese_Taiwan_Stroke_BIN, you must set Server_CSet=BIG5HKSCS, otherwise invalid data will be returned from the server. |
| PostgreSQL | The client locale can be set with the PGCLIENTENCODING environment variable, with the client_encoding configuration parameter in postgresql.conf, or after connection, with the SET CLIENT_ENCODING instruction. Check the pg_conversion system table for available character set conversions. |
| Oracle MySQL | The client locale is defined by the default-character-set option in the MySQL configuration file. The character set could also be changed by program after the connection, with the SET NAMES or SET CHARACTER SET statements, but this not supported: The driver needs to know the character set at connection initialization, and you would have to add this statement in all your programs. |
| Sybase Adaptive Server Enterprise (ASE) | By default, the Sybase database client character set is defined by the operating system locale where the database client runs. On Windows, it is the ANSI code page of the login session (can be overwritten by setting the LANG environment variable), on UNIX it is defined by the LC_CTYPE, LC_ALL or LANG environment variable. You may need to edit the $SYBASE/locales/locales.dat file to map the OS locale name to a known Sybase character set. See Sybase ODBC documentation for more details regarding character set configuration. |
See database vendor documentation for more details.