Enscribe Programmer's Guide

No Automatic Update
You can designate that the alternate-key file contents for an alternate key not be automatically
updated by the system when the value of an alternate-key field changes. Two reasons for doing
so are:
• Certain fields might not be referred to until a later date. Therefore, they can be updated in a
batch (one-pass) mode more efficiently.
• A field can have multiple null values. If that is the case, your application program must have
the alternate-key file open separately and must determine itself whether or not the field contains
a null value. If the field does not contain a null value, your program then inserts the appropriate
alternate-key reference into the alternate-key file.
Alternate Keys in a Key-Sequenced File
You might use alternate keys in a key-sequenced file whose records consist of the vendor name
and the part number. The primary key to this file would be the part number (it could not be the
vendor name, because that is not unique). To produce a report of all parts supplied by a given
vendor, generic positioning would be done via the desired vendor. Then the file would be read
sequentially until the vendor name field is not equal to the desired vendor (at which time the system
returns an end-of-file indication). The records associated with a given vendor would be returned
in ascending order of the part number.
Alternate Keys in an Entry-Sequenced File
You might use alternate keys in an entry-sequenced file within a transaction-logging file. The primary
key (a record address) would indicate the order in which transactions occurred. An alternate-key
field might identify the terminal that initiated a transaction. To list all transactions for a given terminal
in the order in which they occurred, generic positioning uses the field value of the desired terminal,
and the file is then read sequentially.
Alternate Keys in a Relative File
You might use alternate keys in a relative file of employee data. The primary key (a record number)
would be an employee number. One alternate-key field would be an employee name.
Alternate-Key Files
For each primary structured file having one or more alternate keys, you must create at least one
corresponding alternate-key file. An alternate-key file can be partitioned to span multiple volumes.
Each record in an alternate-key file refers to only one alternate key, but the file can contain
references to more than one alternate key. Thus, with five alternate keys, the alternate-key file would
have five records for each primary-file record (provided that none of the primary-file records contains
a null value in any of the alternate-key fields). The primary file can also have multiple alternate-key
files. For example, one might contain references to three of the alternate keys, with a second
alternate-key file containing references to the other two keys.
Here are some reasons you might want to have separate alternate-key files:
• A unique alternate key cannot share a file with other keys of different lengths.
• Each individual alternate-key file is smaller than a combined file with several alternate-key
references, so fewer index references are needed to locate a given alternate key.
• Frequent updating of one alternate key fragments the file. With separate files, this fragmentation
would not affect references to the other keys.
34 Positioning Within Structured Files