File Information Editor
This section provides general information about the File Information Editor with which you can create new files based on file and key specifications you construct. Because this Editor allows you to load information based on an existing file, it is also useful for viewing file and key specifications on existing data files. You can also create a new file based on the file and key specifications of an existing file (similar to the CLONE command for BUTIL, the command-line Maintenance utility).
*Caution: No two files can share the same file name and differ only in their file name extension if both files are in the same directory. For example, do not name a data file Invoice.btr and another one Invoice.mkd in the same directory. This restriction applies because the database engine uses the file name for various areas of functionality while ignoring the file name extension. Since only the file name is used to differentiate files, files that differ only in their file name extension look identical to the database engine.
Open the File Information Editor by clicking Options > Show Information Editor.
Figure 19 File Information Editor
 
File Information Editor Dialog Elements
At the top of the Editor, the following buttons appear:
Displays help for the File Information Editor dialog box.
Data File Info
The Data File Info area, also at the top of the File Information Editor, contains the following controls:
File Specification
The File Specification area is in the middle of the File Information Editor. Table 70 describes the controls in this box.
For information about record length and overhead, see “Record Length” in PSQL Programmer's Guide, which is part of the PSQL Developer Reference.
Key
At the bottom left in the dialog box is the Key group box. Table 71 describes the controls in this area. These controls are specific to the key highlighted in the Key list, not just to the current key segment. When you change the setting for one of these controls, the change affects all segments of the specified key.
Table 71
Key List and Segment List
At the bottom middle of the dialog box, the Key list shows the key numbers defined in a file. (For 6.x and later files, these key numbers do not have to be consecutive; they can have gaps between them.) The Maintenance utility displays the highlighted key’s specifications in the Key box at the bottom left of the dialog box.
Also at the bottom middle of the dialog box, the Segment list shows the key segment numbers defined for the key highlighted in the Key list. The Maintenance utility displays the highlighted segment’s specifications in the Segment box at the bottom right of the dialog box.
In addition, the following buttons appear under the Key and Segment lists:
Because these buttons control key specifications for a file you want to create, you cannot use them to operate on keys in an existing file. If you want to create or drop an index on an existing file, refer to Index Tasks.
Key Segment
At the bottom right in the dialog box is the Key Segment group box. Table 72 describes the controls in this area. These controls are specific to the segment highlighted in the Segment list),
Methods for Handling Duplicate Keys
Multiple records may carry the same duplicated value for index keys. The two methods to keep track of the records with duplicate key values are called linked duplicates and repeating duplicates.
Linked Duplicates
The linked duplicates method uses a chain technique in which each record in the group connects to its neighbors by means of pointers. Each entry on an index page contains a pair of record pointers that indicate the first and last links in the chain of records that duplicate that key's value. This makes each key page entry 4 bytes longer than a repeating duplicates index. In addition, each record on the data page requires an extra 8 bytes of overhead for each linked duplicates index. These 8 bytes consist of two record pointers that point to the next and previous records in the chain.
The first record pointer holds the address of the first, or oldest, record stored. The second pointer holds the address of the most recent, or newest record. After the first record is written but before any others are added, both pointers on the key page entry hold the first record’s address. Subsequent records cause the second pointer to be changed to point to each record as it is added. This permits the record pointer for the last record to be used as the previous-record link of the chain built in the data page when the record is added, and also to be used to locate that previous record.
Repeating Duplicates
With the repeating duplicates method, each duplicate key value is stored on both the index page and within the record on the data page. Each key value has only one record pointer instead of two. This method requires no chaining within the data records and saves the 8 bytes of overhead per index within each record. Since the key value is repeated for each duplicate record, the indexes affected increase in size.
Method Comparisons
The linked duplicates and repeating duplicates methods can be compared based on the following criteria:
Ordering
A linked duplicates index retrieves duplicates in the order in which they were inserted. A repeating duplicates index retrieves duplicates in the order in which they are located within the file. Since location with a file cannot be controlled, the ordering must be considered as random.
Storage
A linked duplicates index requires 12 more bytes for the first occurrence of each duplicate key value. That includes 8 extra bytes on each record and 4 extra bytes for the key page entry. But each duplicate record requires no additional space in the key page, and adds only 8 bytes per record. Therefore, as the number of duplicates per key value increases, and as the size of the key value increases, linked duplicate indexes can save significant storage space used by key pages. However, storage space can increase if your file contains very few records with duplicate keys, the key length is very short, or both.
The following figure exemplifies the amount of storage space saved using linked duplicate indexes. Note that linked duplicate indexes take more space if duplicate records per key value are few. As the number of duplicate records per key value increases, however, linked duplicate indexes require less pages, providing significant space savings.
Figure 20 Comparison of Page Counts for Duplicate Key Methods
 
Performance
Faster performance results when fewer pages are involved in an index search because fewer pages must be read from disk. The linked duplicates method generally uses less physical storage space and therefore provides faster performance. The repeating duplicates method provides a performance advantage if only a small number of keys have duplicates.
Concurrency
The database engine provides page-level concurrency when several concurrent transactions are active on the same file at the same time. This applies to most changes to key pages and for all changes to data pages. The concurrency means that the same page can contain pending changes from separate transactions at the same time, and the transactions can be committed in any order. Repeating duplicate indexes take the most advantage of this concurrency.
Linked duplicate indexes add another limitation on concurrency that does not exist with repeating duplicates. When a new duplicate is created, the new record is linked to another record at the end of the list. This record linking causes two records to be locked instead of one. Since all duplicates are added to the end of the chain of linked records, only one duplicate can be inserted at a time.
Such a record lock conflict usually causes other clients to wait until the first transaction is committed. In a concurrent environment, if all new records use the same duplicate value, then concurrency can effectively be reduced to one transaction at a time. And if transactions are large or long lasting, this serialization can affect performance tremendously.
Performance is typically better if you use repeating duplicate indexes for databases that are updated in a concurrent environment. Therefore, unless you have a compelling reason to use the linked duplicates method, you should use repeating duplicate indexes for databases that are updated in a concurrent environment.
Information Editor Tasks
You perform the following tasks with the File Information Editor:
Loading Information from an Existing Data File
When you load information from an existing file, you are not editing the existing file. Instead, you are loading a copy of the information about that file. Generally, you want to load a data file before performing other tasks with the File Information Editor, but this is not mandatory.
1
Click Load Information at the top of the File Information Editor. The Select File dialog box appears.
Figure 21 Select File Dialog Box
2
The Maintenance utility first attempts to open the specified file as a data file. If the file requires an owner name, the utility prompts you for one. (Because owner names are optional, the file you open may not require an owner name.) If the specified file is not a data file, the utility then attempts to open the file as a description file.
Creating a New File
You can create a new file based on the current information in the File Information Editor or on new information you provide.
1
Click Create File at the top of the File Information Editor dialog box. The Create File dialog box appears.
Figure 22 Create File Dialog Box
2
Specify the controls in the Create File dialog box, which are described in Table 73.
Specifies the type of file to create. If you are creating a description file, you can use the Index Only option, which creates a description file you can use with the BUTIL utility to add an index to an existing data file. (For more information, refer to Creating Indexes.)
Determines whether the utility includes system data in the file. If you choose Use Engine Setting, the utility uses the setting for the System Data configuration option described. If you choose No System Data, the utility does not create system data, regardless of the engine configuration. If you choose Force System Data, the utility creates system data, regardless of the engine configuration.

This is applicable only if the file type is MicroKernel-compatible.
 
Adding Comments to a Description File
The comments are written to the top of the description file when you create the description file. For example, the comment, “This is my file,” appears at the top of the description files as /* This is my file */. If you add additional comments after creating the description file, you need to create the file again to include the additional comments.
1
Click Description Comments. The Description File Comments dialog box appears.
Figure 23 Description File Comments Dialog Box
2
3
Click OK when you are finished entering comments.
Compacting Btrieve Data Files
You can compact a Btrieve data file to remove unused space in it, which typically decreases the file size. You can also perform this procedure using the command-line Maintenance utility (see To compact a Btrieve data file).
1
Click Load Information in the File Information Editor and select the file you want to compact.
2
Click Create File, give the file a new name (which creates a clone) in the Create File dialog box, and click OK.
3
From the Data menu on the main window, select Save. In the Save Data dialog box, enter the name of the original file in the From MicroKernel File box and then specify a name for the output file (for example, <original file>.out) in the To Sequential File box.
4
Click Execute. The Save Data dialog box displays the results of the save. Click Close.
5
From the Data menu, select Load. In the Load Data dialog box, enter the name of the sequential data file you just saved in the From Sequential File box. Then enter the name of the clone file you created in Step 2 in the To MicroKernel File box.
6
Click Execute. The Loading Data dialog box displays the results of the load. Click Close.
You can now compare the size of the original file to the clone file to verify the reduction in size.
Specifying a Key’s Alternate Collating Sequence
You can use an alternate collating sequence (ACS) to sort string keys (types STRING, LSTRING, and ZSTRING) differently from the standard ASCII collating sequence. By using one or more ACSs, you can sort keys as follows:
Files can have a different ACS for each key in the file, but only one ACS per key. Therefore, if the key is segmented, each segment must use either the key’s specified ACS or no ACS at all. For a file in which a key has an ACS designated for some segments but not for others, Btrieve sorts only the segments that specify the ACS.
The ISR tables are provided with PSQL and are based on ISO-standard locale tables. ISR tables are stored in the COLLATE.CFG file, which is installed with the PSQL database engine. Multiple data files can share a single ISR.
1
Click ACS Information.
The Maintenance utility displays the Specify ACS Information dialog box.
Figure 24 Specify ACS Information Dialog Box
2
 
3
4
5
To specify an ACS that sorts string values using an ISO-defined, language-specific collating sequence, you must specify an ISR table name. The Table Name field is limited to 16 characters. For more information on ISRs, refer to the PSQL Programmer's Guide in the Developer Reference.