Copy all of the data in the original file to the destination file, or specify only those attributes whose data to be copied. This means that the destination file may contain a subset of the attributes in the original file.
The user may also specify a different order for the attributes in the destination file. Furthermore, the data in any attribute of the original file may be specified as the item-IDs in the destination file.
Two possible reasons for restructuring file items in this way are:
The user no longer needs to maintain all of the information in the original file items online. To conserve hard disk space, restructure the items by eliminating the attributes that have become superfluous, thereby shrinking the file. This is much more efficient than individually editing the file items in the original file with the Editor.
The user wants the attributes in the original data file items to be ordered differently. The attribute numbers in the file dictionary may be edited to reflect the new sequence, but changing the order of data in each file item would be a more involved task. Reordering the data of every file item may be accomplished with a single REFORMAT statement.
Only the attributes specified as output in the REFORMAT statement are included in the destination file. Furthermore, if the ID-SUPP modifier is included in the statement, the first attribute listed as output becomes the item-ID in the destination file.
What About File Dictionaries?
File dictionaries are not affected by the restructuring operations performed on data file items, which means that the Attribute Definition items must be edited in the file dictionary so they reflect the new item structure. This may involve changing:
The attribute number (AMC) to reflect the new order in which information is stored in the data file
Any correlatives that reference other attributes in the file (for example, the TFILE correlative)
The parameters for Controlling and Dependent attributes
Any mvBASIC programs that access the file, which may necessitate recompiling them
If directing restructured items to another file, the user must either:
Copy the corresponding Attribute Definition items from the original file dictionary to the destination file dictionary with the COPY command and then edit them, or
Create new Attribute Definition items
If the affected Attribute Definition items are not edited, it will be impossible to properly access the newly-structured data when generating an INFO/ACCESS report. Editing a file dictionary in this way is illustrated in the next topic.
Example
Assume that the user wants to restructure the CUSTOMERS file and use the customers’ social security numbers (currently Attribute 8, SS#) as item-IDs instead of the 10-character customer IDs. The user plans to eliminate Attribute 9, COUNTY, in each data file item, but retain Attribute 10, SEX, and plans to split the CUSTOMERS file into two separate files: one file called CUSTOMERS.INDIV for private individuals and the other called CUSTOMERS.CORP for corporations. Do this by referencing Attribute 11, CUST.TYPE, with a selection expression.
Restructuring the CUSTOMERS file in this way consists of these operations:
Creating two new files: CUSTOMERS.INDIV and CUSTOMERS.CORP:
>CREATE-FILE CUSTOMERS.INDIV 7 57 [ 417 ] FILE 'CUSTOMERS.INDIV' CREATED; BASE 8596, MODULO = 7 [ 417 ] FILE 'CUSTOMERS.INDIV' CREATED; BASE 8607, MODULO = 57 >CREATE-FILE CUSTOMERS.CORP 7 57 [ 417 ] FILE 'CUSTOMERS.CORP' CREATED; BASE 8664, MODULO = 7 [ 417 ] FILE 'CUSTOMERS.CORP' CREATED; BASE 8671, MODULO = 57 |
Transferring restructured data file items to these files with two separate REFORMAT statements. The attribute CUST.TYPE in the original CUSTOMERS file is used in a selection expression to separate the data file items into the two new categories:
>REFORMAT CUSTOMERS WITH CUST.TYPE = "I" SS# LAST-NAME FIRST-NAME STREET CITY STATE ZIP PHONE SEX ID-SUPP FILE NAME: CUSTOMERS.INDIV >REFORMAT CUSTOMERS WITH CUST.TYPE = "C" SS# LAST-NAME FIRST-NAME STREET CITY STATE ZIP PHONE SEX ID-SUPP FILE NAME: CUSTOMERS.CORP |
The ID-SUPP modifier is included in these statements. This means that SS#, the first attribute in the output specification, becomes the new item-ID for both of the new files.
The rest of the output specification reflects the new structure of the data items: the COUNTY attribute is not included, nor is the CUST.TYPE attribute since it is now superfluous.
Copying the necessary Attribute Definition items from the CUSTOMERS dictionary to the two new dictionaries:
>COPY DICT CUSTOMERS 'FIRST-NAME' 'LAST-NAME' 'STREET' 'CITY' 'STATE' 'ZIP' 'PHONE' 'SEX' TO: (DICT CUSTOMERS.INDIV . . >COPY DICT CUSTOMERS 'FIRST-NAME' 'LAST-NAME' 'STREET' 'CITY' 'STATE' 'ZIP' 'PHONE' 'SEX' TO: (DICT CUSTOMERS.CORP . . . |
Editing these Attribute Definition items so that the attribute numbers reflect the new item structure.
The table below compares the old and new attribute numbers.
Attribute Name |
Old Number |
New Number |
FIRST-NAME |
1 |
2 |
LAST-NAME |
2 |
1 |
STREET |
3 |
3 |
CITY |
4 |
4 |
STATE |
5 |
5 |
ZIP |
6 |
6 |
PHONE |
7 |
7 |
SS# |
8 |
Item-ID |
COUNTY |
9 |
Not used |
SEX |
10 |
8 |
CUST.TYPE |
11 |
Not used |
See Also