REDEFINE command: Difference between revisions
| Line 198: | Line 198: | ||
<p class="code">REDEFINE EXPENSE (IMMED 20) | <p class="code">REDEFINE EXPENSE (IMMED 20) | ||
</p> | </p> | ||
====CHUNK | ====Redefining CHUNK fields==== | ||
The syntax to redefine a [[DEFINE_FIELD_command#CHUNK_attribute|CHUNK]] field is as follows: | The syntax to redefine a [[DEFINE_FIELD_command#CHUNK_attribute|CHUNK]] field is as follows: | ||
<p class="syntax"> | <p class="syntax"> | ||
| Line 220: | Line 220: | ||
<li>you cannot REDEFINE a chunk target to non-ordered</li> | <li>you cannot REDEFINE a chunk target to non-ordered</li> | ||
</ul> | </ul> | ||
====Redefining INVISIBLE fields==== | ====Redefining INVISIBLE fields==== | ||
<p>You cannot use the REDEFINE command to add a new index to a field with the INVISIBLE attribute that is in a file that has been used, so that MSTRADD is nonzero. For an invisible field the REDEFINE command cannot specify the KEY, ORD CHAR, and ORD NUM attribute nor the NUMERIC RANGE attribute, unless the field was originally defined with that attribute.</p> | <p>You cannot use the REDEFINE command to add a new index to a field with the INVISIBLE attribute that is in a file that has been used, so that MSTRADD is nonzero. For an invisible field the REDEFINE command cannot specify the KEY, ORD CHAR, and ORD NUM attribute nor the NUMERIC RANGE attribute, unless the field was originally defined with that attribute.</p> | ||
Revision as of 22:38, 25 July 2013
Summary
- Privileges
- File manager
- Function
- Modifies the definition of a field in a Model 204 file
Syntax
REDEFINE [FIELD] {field-description [field-description]... | fieldname WITH attribute [attribute]...}
Where:
| field-description | takes the following form:
fieldname [(attribute [attribute]...)] |
||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| fieldname | (1 to 255 characters) is the name of a field in the open Model 204 file. | ||||||||||||||||||||||||||||||||||||||||
| attribute | is one of those listed in the table below. All attributes are described in detail in the Model 204 File Manager's Guide.
* You can specify FEW-VALUED and MANY-VALUED only if a field is being redefined from NON-FRV NON-CODED to FRV NON-CODED. |
Syntax notes
If FIELD is specified or the WITH form of the REDEFINE command is used, only one field can be redefined; otherwise, multiple fields can be redefined.
The attributes must be enclosed in parentheses unless WITH is specified.
Attributes must be separated by commas or by one or more blanks.
REDEFINE can be specified only in file context.
Example
REDEFINE SOC SEC (KEY,NR,LEVEL 0) REDEFINE AGE WITH KEY
Usage notes
The REDEFINE command allows the file manager to alter a field definition without having to reinitialize or reload the file in which the field is stored.
The file manager can specify as many attributes as are needed. OCCURS, LENGTH, and PAD (see DEFINE FIELD) cannot be included. For each attribute, only one of the alternatives shown above can be specified. For example, either KEY or NON-KEY can be specified, but not both.
If an attribute is specified in the DEFINE command, but not changed by the REDEFINE, that attribute remains in effect for the field.
A field can be REDEFINED with the UNIQUE attribute. However, if non-unique values are found during REDEFINE processing, the REDEFINE fails and the following error message is produced for each non-unique value:
*** M204.1701: NON-UNIQUE VALUE value FOUND FOR FIELD fieldname IN RECORD NUMBER n; CONFLICTS WITH RECORD NUMBER n
FIELD keyword
The keyword FIELD is required before field names that begin with the word FIELD, PRINTER, or DATASET. It is optional before other field names. If FIELD is specified, only one field can be redefined per command.
The following examples both redefine a field with the name POLICYHOLDER:
REDEFINE FIELD POLICYHOLDER (KEY) REDEFINE POLICYHOLDER (KEY)
The following example redefines a field with the name FIELD LOCATION. In this example the keyword FIELD must precede the name of the field name to avoid confusing Model 204:
REDEFINE FIELD FIELD LOCATION (ORD)
ORDERED fields
The NON-ORDERED and ORDERED attributes relate to the Ordered Index. The NON-ORDERED attribute can be used to eliminate the Ordered Index for a given field.
The ORDERED attribute followed by a new tree type can change the tree type of an ORDERED field. The tree type can be either CHARACTER or NUMERIC. Changing the tree type deletes the old tree type.
If a field already is defined as ORDERED, the REDEFINE command can change the related attributes by specifying the attribute and a new value. A change to the LRESERVE, NRESERVE, SPLITPCT, or IMMED attribute does not cause any change to the existing Ordered Index but modifies the effect of any updates.
Refer to the discussion of the "DEFINE FIELD: Field names and attributes" for more information on the Ordered Index field attributes.
The following example eliminates the Ordered Index for the TAX field:
REDEFINE TAX (NON-ORDERED)
The following example changes the tree type of the Ordered Index CHARGE field:
REDEFINE CHARGE (ORDERED CHAR)
The following example changes the related attributes of an Ordered Index field:
REDEFINE EXPENSE (IMMED 20)
Redefining CHUNK fields
The syntax to redefine a CHUNK field is as follows:
REDEFINE FIELD chunkFieldName WITH newFieldAttributes
Because CHUNK fields are ORDERED, only the following attributes can be changed:
- SPLIT
- IMMED
- LRESERVE
- NRESERVE
Restrictions:
- you cannot REDEFINE a non-CHUNK field to a CHUNK field
- you cannot REDEFINE a CHUNK field to a non-CHUNK field
- you cannot REDEFINE a chunk target to non-ordered
Redefining INVISIBLE fields
You cannot use the REDEFINE command to add a new index to a field with the INVISIBLE attribute that is in a file that has been used, so that MSTRADD is nonzero. For an invisible field the REDEFINE command cannot specify the KEY, ORD CHAR, and ORD NUM attribute nor the NUMERIC RANGE attribute, unless the field was originally defined with that attribute.
The behavior of the REDEFINE command changed in Version 5.1. Prior to Version 5.1, when you redefined an invisible field with options that added a new index, such as KEY, NUMERIC RANGE, or ORDERED, the redefinition for the field was accepted. However, the new index was not actually built (and could not be because the field was invisible). Now, if you redefine an invisible field with options that specify a new index for the field, the redefinition is rejected with the following message:
M204.0411: CONFLICTING ATTRIBUTES: INVISIBLE FIELD WITH NEW INDEX
Exception
The following exception applies: in the case where no records have ever been stored in the file, and that case only, redefining an invisible field can specify options that add a new index for the field.
The behavior of the REDEFINE command does not change when used with invisible fields and options that do not add a new index for the field.
Update units
When it processes REDEFINE, Model 204 ends any update unit in progress and begins a non-backoutable update unit.
Redefining Large Object fields
You can redefine a Large Object field, if the file is empty and you specify that the that the field is (BLOB NCLOB) or (CLOB NBLOB). For example, the following statement is unsuccessful:
REDEFINE FLD_LOB (BLOB) *** 2 M204.0411: CONFLICTING ATTRIBUTES: BLOB AND CLOB
However, the following statement is successful:
REDEFINE FLD_LOB (BLOB NCLOB)
Furthermore, you can redefine a field as a Large Object field, if no data has been entered in the field. For example, the following statements are unsuccessful:
REDEFINE FLD_LOB (BLOB NCLOB) *** 2 M204.0411: CONFLICTING ATTRIBUTES: FILE NOT EMPTY REDEFINE FLD_LOB (KEY NCLOB) *** 2 M204.0411: CONFLICTING ATTRIBUTES: FILE NOT EMPTY