UNICODE data is notoriously difficult to handle. It requires an intimate knowledge of the data and micro-management of the search process to avoid inappropriate conversions and to request conversions when necessary.
Batch Searches
The most reliable approach to debugging a new search is to use a batch search client such as relate. A batch client has several advantages over an online search client:
the input file can be viewed and/or manipulated with a hex editor, so you have precise control over the input data.
search records read from a file are not subject to conversions performed by the Operating System. Use fixed length records and specify
-b
to read the file in binary mode. This avoids characters being interpreted as
CR/LF
and being converted to
LF
.
only server side tracing is necessary to verify the search process.
Online Searches
In contrast, an online search client has less control over the input data because the Operating System may perform unexpected conversions while the data is entered:
If the data is typed, the characters that end up in the input buffer are dependent on the keyboard driver, language, and locale being set correctly.
A cut and paste operation may also perform conversions on the data. It may be corrupted even before you hit the enter key to start the search.
The correct search results may look wrong if the locale has been configured incorrectly due to incorrect rendering of the characters.
If you do decide to use the online client, make sure to use the MDM-RE 950 client and enable the client side logging facility to produce a hex dump of the input data.
Server-side Search Tracing
The
Search Performance
chapter of the
DESIGN GUIDE
documents provide informatation on how to enable the Search Trace facility. This feature is particularly useful when debugging
UNICODE
problems as it logs the Search Record and File Records in hexadecimal format. It also displays the records before and after view conversion and/or