GeniusConnect Unicode releases
The Unicode version implements support for Non ASCII languages (Chinese, Japanese etc..).
Do not use the Unicode version in the following situations:
-Your Outlook version does not support unicode
Only MS Outlook 2003 and higher has full unicode support
Previous versions of Outlook provided support for multilingual Unicode data in the body of e-mail messages. However, Outlook data — such as the To and Subject lines of messages and the ContactName and BusinessTelephoneNumber properties of contact items — was limited to characters defined by your system code page.
-Your database does not support Unicode
-Your table column does not support Unicode (using char/varchar columns instead of nchar/nvarchar)
-Your ODBC driver does not support Unicode
-Set unicode syntax in "Assign Table" dialog
Some database systems are using special syntax when dealing with Unicode strings.
For example in SQL Server you must precede all Unicode strings with a capital letter N.
-Use nchar/nvarchar columns instead of char/varchar if you need to store unicode data
-Check your Database and ODBC driver for Unicode support
Since the Unicode version can cause problems with pre-Outlook 2003 versions and older ODBC drivers and databases, we will not support Unicode installation on Outlook 2000,2002 or old ODBC drivers without Unicode support
Unicode Support in Databases
Not surprisingly, the implementation of Unicode data types varies from vendor to vendor. For example, the Microsoft SQL Server 2000 implementation of Unicode provides data in UTF-16 format, while Oracle provides Unicode data types in UTF-8 and UTF-16 formats . A consistent implementation of Unicode not only depends on the operating system, but also on the database itself.
Unicode Support in ODBC
Prior to the ODBC 3.5 standard, all ODBC access to function calls and string data types was through ANSI encoding (either ASCII or DBCS). Applications and drivers were both ANSI-based.
The ODBC 3.5 standard specified that the ODBC Driver Manager (on both Windows and UNIX) be capable of mapping both Unicode function calls and string data types to ANSI encoding as transparently as possible. This meant that ODBC 3.5-compliant Unicode applications could use Unicode function calls and string data types with ANSI drivers because the Driver Manager could convert them to ANSI. Because of character limitations in ANSI, however, not all conversions are possible.
The ODBC Driver Manager version 3.5 or later, therefore, supports the following configurations:
ANSI application with an ANSI driver
ANSI application with a Unicode driver
Unicode application with a Unicode driver
Unicode application with an ANSI driver
A Unicode application can work with an ANSI driver because the Driver Manager provides limited Unicode-to-ANSI mapping. The Driver Manager makes it possible for a pre-3.5 ANSI driver to work with a Unicode application.