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