HP 3000 Manuals

Limitations [ Information Access Server: Database Administration ] MPE/iX 5.0 Documentation


Information Access Server: Database Administration

Limitations 

Four problem situations are discussed below:  what happens to Round Trip
data, the case of mute languages, improper sorting on certain characters,
and selection criteria for records.

Round Trips 

Round trips involve the movement of data through at least one Best Fit
mapping, with the potential for loss of information.

Here are situations that qualify as round trips:

   *   The PC user accesses an IMAGE or file table, saves the result on
       the PC, and later uploads the PC table to the HP 3000.

   *   The PC user uploads PC data to a saved table on the HP 3000, then
       later downloads the data to the PC.

Mute Languages 

A special case of the round trip problem is the exception discussed above
for mute languages, where the incorrect mapping occurs on the ROMAN-8 to
ISO-7 part of the journey.

For example, a correctly downloads from the host to the PC as "Lowercase
a Circumflex", but the circumflex is lost on a subsequent upload.

Sorting 

Rules for sorting differ depending on whether data is being sorted or
sorts are being done within the Administrator Utility.

Sorting Data.   

Our sorting routines are not as sophisticated as NLS sorting (which is
available when ROMAN-8 is your character set).

Data is sorted according to the specified character set.  However, there
are some cases where sorting is inexact:

   *   Our sorting routines cannot handle two-character sort keys.  For
       example, in DANSK/NORSK, "Lowercase ae Ligature", which should
       follow "ad", will follow "az"; in DEUTSCH, "German Sharp s", which
       should follow "ss", will come just before "t".

   *   No language-specific sorting rules are supported.  In ESPANOL, for
       example, "ch", which should follow "cz", will follow "cg".

   *   In the mute languages, doubled characters will not sort correctly.
       For example, "a", which should follow "a", will be sorted as ""
       followed by "a".

In many cases, characters will sort correctly.  For example, in DEUTSCH,
"Lowercase u Umlaut" (whose ROMAN-8 decimal value is 207) is kept as
decimal value 125, and Access Server instructs SORT/3000 to sort this
decimal value after "u".

All Other Sorts.   

Sorts occurring in the Administrator Utility may give rise to some
discrepancies.  For the nine ISO-7 character sets, our sorting routines
operate according to the USASCII collating sequence.

In FRANCAIS and FRANCAIS MUTE, for example, if "Lowercase a Grave"
appears as a character in a table name, it is mapped to "Commercial At"
and sorted as such in the Administrator Utility.  (It will not sort as an
"a".)

Selection Criteria 

When selection criteria are specified (by the PC user, by a Host Batch
Facility command file, or by the DBA defining view tables in the
Administrator Utility), how the selection is done will depend on where
the data resides.

IMAGE and File Data.   

Character constants in the selection criteria are Best Fit mapped to the
ISO-7 character set before being compared against IMAGE databases and
files.  The Best Fit mapping means that localizable characters that
aren't in your character set can cause problems.

Wildcard Characters.   

In defining view tables, if you use the MATCH operator in the Where
Clause, then the wildcard character you should use for matching variable
length strings is not "Commercial At" (@) but "Asterisk" (*) instead.
The same is true of selection criteria in the Host Batch Facility.

For example:

                      PRODUCT-NBR MATCH "PAP*" 

This is true whether or not your ISO-7 character set contains the @
character.


NOTE Users running Access PC always use the asterisk regardless of which character set the site is using.


MPE/iX 5.0 Documentation