Portable Data Files (-nvarchar Flag)
The character set used by your installation affects the character encoding used by copydb and unloaddb to generate the data files.
Regardless of your installation’s character set, you can generate portable data files by using the –nvarchar flag on copydb and unloaddb. The flag requests that all character strings be copied or unloaded using UTF-8 encoding.
Using the –nvarchar flag is especially useful when:
• When you are migrating to Unicode enabled applications and need to unload your existing local character set data and reload it into a Unicode database with UTF8 character set
• The target database is part of an Actian Vector installation, which requires the UTF8 character set
Note:
• Scripts generated using the –nvarchar flag cannot be used to reload data into a non-Unicode database.
• When unloading data from a non-UTF8 installation and reloading it into a UTF8 installation, data truncation may occur in the following instances:
– If tables contain columns of type C or TEXT. If the installation for the source database uses the ISO88591 character set, the non-ASCII characters will expand to consume two bytes.
– If the source database is an NFC database and the target database is an NFD database, a greater column width may be required to avoid truncation during reload.
• The copy.in and copy.out scripts generated using the ‑nvarchar flag will fail to execute against earlier releases of Ingres, which are not able to coerce C and TEXT column types to and from UTF8.
• The value of II_MONEY_FORMAT is not transliterated into UTF-8 encoding in the copy.in, copy.out, or the generated data files. Characters such as the Euro (€) or the Yen (¥) will not be UTF-8 encoded and will not display correctly unless they are viewed using the character set under which they were generated. The actual money value is not affected when the data is reloaded on a target installation using a different character set.
• The ‑nvarchar flag automatically uses II_DATE_FORMAT=SWEDEN. This format, which is compatible with ANSI dates, allows the data to be loaded into non-Ingres targets that use ANSI dates. It does not affect the date values when reloading the data into an Ingres database.
• The DDL for user tables will be updated to convert column definitions from char to nchar, varchar to nvarchar, and long varchar to long nvarchar. ABF applications and other dependencies are not automatically updated; furthermore, ABF does not support Unicode data types.