Client application code-set conversion
These topics summarize the code-set conversion that a client product performs.
For more general information about code-set conversion, see Perform code-set conversion.
- The code sets of the client and database locales do not match.
- A valid object code-set conversion exists for the conversion between the client and database code sets.
When the client application begins execution, it compares the names of the client and database locales to determine whether to perform code-set conversion. If CLIENT_LOCALE is not set, the client application assumes that the client locale is the default locale. If DB_LOCALE is not set, the client application assumes that the database locale is the same as the client locale (the value of the CLIENT_LOCALE setting).
If the client and database code sets are the same, no code-set conversion is needed. If the code sets do not match, however, the client application must determine whether the two code sets are convertible. Two code sets are convertible if the client can locate the associated code-set-conversion files. These code-set-conversion files must exist on the client computer.
On UNIX™, you can use the glfiles utility to obtain a list of code-set conversions that your HCL OneDB™ product supports. For more information, see The glfiles utility (UNIX). On Windows™, you can examine the directory %INFORMIXDIR%\gls\cvY to determine the GLS code-set conversions that your HCL OneDB product supports. For more information about this directory, see Code-set-conversion files.
If no code-set-conversion files exist, the client application generates a run time error when it starts to indicate incompatible code sets. If code-set-conversion files exist, the client application automatically performs code-set conversion when it sends data to or receives data from the database server.
- All data values that are processes are handled in the client code set.
- All databases that the client application accesses on a single database server use the same database locale, territory, and code set. When the client application opens a different database, it does not recheck the database locale to determine if the code set has changed.
For example,
suppose your client application has CLIENT_LOCALE set
to en_us.1252 and DB_LOCALE set to en_us.8859-1.
The client application determines that it must perform code-set conversion
between the Windows Code
Page 1252 (in the client locale) and the ISO8859-1 code set (in the
database locale). The client application then opens a database with
the French fr_fr.8859-1 locale. The database server sets the
eighth character field of the SQLWARN array to W because
the languages and territories of the two locales are different. The
database server then uses the locale of the database (fr_fr.8859-1)
for the localized order of the data.
Your application, however, might use this connection. It might be acceptable for the application to receive the NCHAR and NVARCHAR data that is sorted in a French localized order. Any code-set conversion that the client application performs is still valid because both database locales support the default ISO8859-1 code set.
Instead, if the application opens a database with the Japanese SJIS (ja_jp.sjis) locale, the database server sets the SQLWARN warning flag because the language, territory, and code sets differ. The database server then uses the ja_jp.sjis locale for the localized order of the data.
Your application would probably not continue with this connection. When the client application started, it determined that code-set conversion was required between the Windows Code Page 1252 and ISO8859-1 code set. The client application performs this code-set conversion until it terminates.