|
|
|
If a key segment mode (the last member of the ISEG structure) includes a modifier for an extended key segment definition (e.g., REGSEG | UNCSEG), then the particular extended key segment definition to use for this segment is determined according to the following hierarchy. Use the definition specified for:
The PutXtdKeySegmentDef() routine can specify extended key segment definitions for each of these six levels. To make this hierarchy more concrete, consider this example. Data file customer.dat has an index file named customer.idx. The index file customer.idx contains 3 indexes: a customer number index, a customer name index, and a customer status index. The customer name index is comprised of one Unicode segment. If an extended key segment definition has been specified for this particular segment, then it is used. If not, and if an extended key segment definition has been specified for the customer name index, then it is used. If not, and if an extended key segment definition has been specified for the host index file (customer.idx), then it is used. If not, and if an extended key segment definition has been specified for the associated data file (customer.dat), then it is used. If not, and if an extended key segment definition has been specified for the entire application, then it is used. If not, and if the application is on a server, and if an extended key segment definition has been specified for the server, then it is used. If not, a USEG_ERR (707) occurs: there is no extended key segment definition to use.
Except when an extended key segment definition has been specified for a particular key segment, the determination of which extended definition to use (as specified in the above hierarchy) is not determined until the first use of the key segment. By “first use” we mean either a reference to a key segment, say in a call to AddRecord() or AddVRecord(), after a file has just been created; or upon opening a file that contains extended key segment references that were not used after file creation and subsequent file closure. Upon this first use, if a default from one of levels 2 through 5 is used, then the particular definition is stored in the host index file so that the definition can travel with the physical file. (This automatic storage will not occur if the host index file is opened read only or has DISABLERES in its file mode.)
This hierarchy has been implemented to simplify the use of extended key segment definitions. One can easily imagine a Unicode dependent application that will only process Unicode key segments for one language, although the language may change from one site to another. By using a single call to PutXtdKeySegmentDef() at the application level, the details of the Unicode segment including the locale can be specified at program startup. All extended key segments can then default to this application definition. And since the definition will be added to the host index files, the index files created this way become self-sufficient.
It is important to note that except for a segment specific extended definition, there can be more than one extended key segment definition for each of the remaining five levels (2 through 6). But there can only be one extended key segment definition at each level for a particular type of segment. For example, there can be at most one ICU Unicode extended key segment definition at each level. (At this time we do not have any other type of extended key segment definition, and this is likely to change in time.)
Once an extended key segment definition has been specified at a particular level (for a particular type of segment), an attempt to specify another definition at the same level results in an error. This is in part because of the “first use” strategy noted above, and because one should not change a definition if key values already exist.
