GLS support

When the database server starts a UDR, the routine runs in the locale that DB_LOCALE specifies. Consequently, the database server automatically converts parameters, return values, and output values between the DB_LOCALE code set and the Unicode code set so that Java™ code can use the values.

However, when a Java™ UDR creates a JDBC connection to the database server for access through SQL, you can set DB_LOCALE into the connection URL to control conversions and formatting between the Unicode code set and the code set of the database server locale. This setting of DB_LOCALE overrides any environment settings. In fact, DB_LOCALE does not need to be set in the environment. Similarly, you can also set DBDATE, GL_DATE, and DBCENTURY into the URL connection to control date conversion and formatting.

For example, when a UDR sends string or date data to the database server in an insert, the database server converts the data from Unicode to the locale that DB_LOCALE specifies, or it interprets dates and intervals by using your DBDATE or GL_DATE setting.

When the database server returns data to the Java™ UDR, the database server does the opposite conversion, so Java™ code sees only Unicode.

You can extend the Java™ runtime environment that is distributed with server. You can extend the default list of character sets by creating a JAR file that contains your own CharsetProvider and Charset class implementations. Copy the custom CharsetProvider JAR file into the $INFORMIXDIR/extend/krakatoa/jre/lib/ext directory. For more information about how to build a custom CharsetProvider JAR file, see that Java™ API documentation for CharsetProvider.
Important: This method must be used only for situations where the server supports a character set that does not have an equivalent (or does not exist) within the Java™ runtime environment that is distributed with server.