Switching to a Unicode Environment
As mentioned at the beginning of this chapter, OpenROAD 12.0 provides transparent Unicode support, enabling applications to handle single-byte, multi-byte, and UTF-8 data with little or no changes to existing coding. If you plan to use the OpenROAD 12.0 transparent Unicode feature, then depending upon your application, there may be some minor code changes involved.
If this is part of your migration plans, be aware of the following points:
• There is no need to modify your OpenROAD application data types, but you might have to change the lengths of your varchar variables.
• You will need to move to a Unicode-enabled database in a new installation with II_CHARSET set to UTF8.
• When II_CHARSET is set to UTF8, the OpenROAD 5.1 default system font "MS Sans Serif" is changed for OpenROAD 12.0 to "Microsoft Sans Serif," which enables more Unicode glyphs to be displayed by default. However, if Microsoft Sans Serif proves insufficient for your Unicode application needs, you may specify a different system font in the appedtt.ff font file (or whichever font file II_FONT_FILE points to).
• In OpenROAD 12.0 when the environment variable II_CHARSET is set to UTF8, all characters are encoded as UTF-8 code points. All characters should display correctly if the current font supports them. If a character cannot be displayed using the current font, a substitution glyph—typically a square or bold vertical bar—will be displayed in its place. By default OpenROAD uses a generic logical font most suitable for the current code page, but this does not mean it cannot display characters outside of the current code page. For any given character, the Microsoft Windows generic font mapper searches for the closest matching physical font to display it.
Font coverage varies between operating systems. Windows 7 fonts have broader coverage than Windows XP fonts. For example, in some situations Windows 7 displays the correct glyph while older systems such as Windows XP display a substitution glyph. Possible solutions to font-related display problems are to change the locale, define a specific font for your applications, or migration to a newer operating system.
• In a UTF8 environment, some characters can take up more than one byte (for example, some extended ASCII characters). If you use these characters as part of component or application names, they could be silently truncated because they are stored as varchar(32) types in the system catalog. To avoid this issue, use only ASCII characters as component and application names. Another approach is to shorten the names so that they do not take up the whole 32 bytes.
• You may need to change your schema data types (DDL). Although it is not necessary with Ingres 9.2 and above, it is usually a good idea to convert the DDL to use the Unicode types such as nvarchar even if you will be using Ingres as the backend RDBMS.
• Conversion of your schema data types (DDL) is mandatory if you are using Enterprise Access, so if your solution runs against multiple databases, changing the DDL in all cases makes for consistency.
Last modified date: 06/25/2024