This section demonstrates how to create a new RMSfile with lfedit. We will create an RMSfile like the mag file in the Demonstration Subscription System with the addition of an alias name given to the magazine field.
Each record in this file has four fields, i.e., magazine code (which has two names), magazine title, annual subscription rate, and the total number of subscribers. The Number of Elements value for each field should be set to the default value. Their corresponding Field Names, Data Types, Field Lengths, and Descriptions are listed in the following table:
Field Data Field
Name Type Length Description
magazine string 16 magazine code
key alias (default) alias for magazine
title string 36 magazine title
year_rate money (default) subscription rate
subscribers integer (default) number of subscribers
Before you can create the RMSfile, you must have a database to put the RMSfile in. You can create a new database named mydb as follows:
c:\> dbadmin -cv mydb "current directory"\mydb
c:\> mkdir mydb\data
c:\> mkdir mydb\def
c:\> mkdir mydb\rpt
To create a new RMSfile mag in the mydb database, enter the following:
c:\> lfedit -c mydb~mag
Lfedit displays the first form as shown:
Press the ADD key to enter data on the first form. For this example, select the default values for each field. The form should look as follows:
Press the STORE key to record these values and switch to the next form. The screen should look like the following:
Notice that we are still in ADD mode. You can now enter the first Field Description, after which the screen should appear as follows:
Press the STORE key to record the information for the current Field Description and display a blank form for the next one, as shown below:
Note that ADD mode is still active, thus allowing uninterrupted continuation of entry.
We must enter the key field description next, since it is an alias of the magazine field (the previous field). The screen should appear as follows:
When entering an alias Field Description, it is critical to remember the following Field Name convention which, stated simply, says that "an alias-type field is always associated with the PREVIOUS field", i.e., the field which immediately precedes the alias field. Therefore, if you somehow alter the relationship between those Field Descriptions, the field with which an alias-type field is associated may be changed.
If, for instance, after storing this Field Description, you were to add a Field Description immediately preceding it (i.e. in-between the magazine and key Field Descriptions), the alias name key would no longer refer to the magazine field, but would instead refer to the newly added field. Likewise, were you to then remove the newly added Field Description, the alias name key would once again refer to the magazine field. When more than one alias name is assigned, each name merely refers to the PREVIOUS Field Description until the Field Name which applies to the physical data field within the record is reached. Entry of the first Field Description of a File Definition as an alias field is not in accordance with Field Name conventions and results in unpredictable behavior on the part of various C/Base programs. Example 2 in the next section further illustrates the implementation of alias-type fields.
At this point, press the STORE key to record the information for the alias field, after which the screen should look as follows:
Once again, ADD mode is still active, thus allowing you to continue entry of the remaining Field Descriptions.
After all of the information for all the Field Descriptions has been entered and stored, the screen should appear as follows:
Press the SWITCH key to display the form for entering the Primary Key Field Names. When the new form is displayed, part of the screen scrolls up. The following illustration shows how the screen should look:
Notice again that we are still in ADD mode. For our example, the Primary Key is the magazine code field, magazine. This should be entered exactly as it appears in the following screen display:
Press the STORE key to record the Primary Key definition and switch to the next, and last, form. This form, as shown below, defines the Secondary Key Field Names:
Once again, the screen is scrolled up to make room for the new form. Notice also that we are still in ADD mode. Entry of Secondary Key definitions is now possible. Let us define the title field as a Secondary Key Field Name as shown below:
Press the STORE key to record this Secondary Key and display a new form for the next Secondary Key, as shown below:
In this example we will not add any other Secondary Keys. However, if more Secondary Keys were necessary, we could continue to enter and store them. Once all of the Secondary Keys for the current File Definition have been entered, press the SWITCH key to clear the display and redisplay the first form (at which point you can modify the file definition), or press the EXIT key (which writes the current RMS definition file) and exits from the RMS definition process.
After you press the EXIT key, lfedit performs the following steps:
1. Writes the RMS definition file in def\mag relative to the database home directory
1. Creates an empty RMSfile from the RMS definition file. The new RMS file is put in the data directory relative to the database home directory
1. Adds the logical name mag to the logical RMSfile catalog for database mydb.