Neoview Character Sets Administrator's Guide (R2.4, R2.5)

Table 5-1 Troubleshooting Symptoms, Causes, and Recommended Corrective Actions for Users
(continued)
Recommended Corrective ActionsProbable CausesSymptomsProblem Type
Use only characters that are supported
(compatible) across all the client
workstations. Install all the supported
fonts on every workstation. If a
Neoview ODBC driver is used, it
might also be necessary to configure
the same character set on every
workstation. For more information, see
Appendix B (page 47).
A client workstation attempted to
query character data stored in the
Neoview database that is not
compatible with its configured
character set. In the Unicode
configuration, workstations can
only display character fonts that
have been that have been installed
on them. When you use a
Neoview ODBC driver-connected
application to query the database
in the Unicode configuration, each
client workstation can only view
character data that is encoded in
the character set that is currently
configured on that workstation.
When a client
workstation attempts
to view character data
from a Neoview ODBC
driver-connected query
application, these
symptoms occur:
• A translation error
is generated stating
that you inserted
characters from
another client
workstation that are
not supported on
the retrieving
workstation.
• Replacement
characters (question
marks by default)
are displayed from
the query
application.
Incompatible
client locale
errors when an
ODBC
driver-connected
query
application is
used in the
Unicode
configuration
• If possible, reduce the size of the
key to conform to the 255-byte limit.
• Otherwise, do not use the NO
PARTITION option, particularly in
tables that store multibyte
characters.
A table with the NO PARTITION
option specified imposes lower
size limits on keys, data blocks,
and table row sizes than does a
hash-partitioned table.
When you create a
table with the NO
PARTITION option
specified and define a
key for a character
column, you get an
error stating that you
have exceeded the
255-byte size limit.
Key size length
limit exceeded
when NO
PARTITION is
specified for a
table
Avoid using the catalog API for SJIS
data that is likely to contain 0x5C as
the second byte.
Internally, Neoview SQL uses a
LIKE predicate when handling
catalog API parameters.
Therefore, Neoview SQL
interprets the second byte, 0x5C,
of a SJIS character in the
parameter as an escape sequence
(\) and expects a pattern
matching character, such as %, or
_, to follow. Hence, Neoview SQL
returns an SQLFetch error.
Neoview SQL returns
an SQLFetch error to
the client application
and issues an event
message that contains
this error message:
ERROR[8410] An
escape character
in a LIKE pattern
must be followed
by another escape
character, an
underscore, or a
percent
character.
SQLFetch error
when an ODBC
parameter for
the catalog API
contains a SJIS
character that
has 0x5C as the
second byte
SJIS Character Mismatches
Over time, multiple character hexadecimal values have been assigned to the same glyph in the
SJIS character set. There are now approximately 400 SJIS character hexadecimal values for which
one or more other SJIS character hexadecimal values represent the same character glyph and
map to the same Unicode code point value.
It is possible, then, for customer applications to store and retrieve different SJIS character
hexadecimal values for the same character glyph. In a SJIS configuration with an ODBC connection,
when these SJIS character hexadecimal values are provided in SQL statement character string
literals and sent to the Neoview database and then retrieved, they can undergo one or more
42 Troubleshooting Guidelines for Neoview Character Sets Users