Field attributes: Difference between revisions

From m204wiki
Jump to navigation Jump to search
 
(16 intermediate revisions by 4 users not shown)
Line 1: Line 1:
===File model feature===
==File model feature==
<p>The file manager defines fields and assigns attributes to each field, as described in [[Defining_Fields_Manually|Defining Fields Manually]]. The field attributes listed on this page are of interest to the application developer.</p>
<p>
<p>You can enforce file-wide constraints on files and fields with two <var class="product">Model&nbsp;204</var> file models:</p>
The file manager defines fields and assigns attributes to each field, as described in [[Defining fields manually]]. The field attributes listed on this page are of interest to the application developer.</p>
<p>
You can enforce file-wide constraints on files and fields with two <var class="product">Model&nbsp;204</var> file models:</p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 7: Line 9:
<th>Action...</th>
<th>Action...</th>
</tr>
</tr>
<tr>
<tr>
<td>Numeric Validation </td>
<td>Numeric Validation </td>
<td>Causes <var class="product">Model&nbsp;204</var> to perform numeric data type validation on fields defined as FLOAT or BINARY.</td>
<td>Causes <var class="product">Model&nbsp;204</var> to perform numeric data type validation on fields defined as FLOAT or BINARY.</td>
</tr>
</tr>
<tr>
<tr>
<td>1NF (First-Normal Form) </td>
<td>1NF (First-Normal Form) </td>
Line 16: Line 20:
</tr>
</tr>
</table>
</table>
<p>Use the [[FILEMODL parameter]] to set a file model when creating a file. </p>
<p>
 
Use the [[FILEMODL parameter]] to set a file model when creating a file. </p>
===Field attribute descriptions===
 
====AT-MOST-ONE and REPEATABLE attributes====
==Field attribute descriptions==
<p>If a field is defined as having the AT-MOST-ONE attribute, <var class="product">Model&nbsp;204</var> prevents multiple occurrences of that field in any given record. However, unlike fields with the OCCURS attribute, AT-MOST-ONE fields are not specifically preallocated. </p>
<p>If a field is not defined as AT-MOST-ONE, then it is REPEATABLE.</p>
===AT-MOST-ONE and REPEATABLE attributes===
<p>REPEATABLE is the default except for First-Normal Form files, where AT-MOST-ONE is required on all fields. </p>
<p>
<p>See the discussion [[#File model feature|File model feature]].</p>
If a field is defined as having the AT-MOST-ONE attribute, <var class="product">Model&nbsp;204</var> prevents multiple occurrences of that field in any given record. However, unlike fields with the OCCURS attribute, AT-MOST-ONE fields are not specifically preallocated. </p>
====AT-MOST-ONE versus UNIQUE attributes====
<p>
<p>Although the names of the UNIQUE and AT-MOST-ONE attributes sound similar, they have very different meanings: </p>
If a field is not defined as AT-MOST-ONE, then it is REPEATABLE.</p>
<p>
REPEATABLE is the default except for First-Normal Form files, where AT-MOST-ONE is required on all fields. </p>  
===AT-MOST-ONE versus UNIQUE attributes===
<p>
Although the names of the UNIQUE and AT-MOST-ONE attributes sound similar, they have very different meanings: </p>
<ul>
<ul>
<li>UNIQUE affects the value of the field</li>
<li>UNIQUE affects the value of the field</li>
</li>
<li>AT-MOST-ONE affects the number of field occurrences per record</li>
<li>AT-MOST-ONE affects the number of field occurrences per record  
</li>
</li>
</ul>
</ul>
<p>For example, if a Social Security field within an EMPLOYEE file is both UNIQUE and AT-MOST-ONE; the UNIQUE attribute ensures that the social security number for every employee is different, and AT-MOST-ONE ensures that each employee has only one social security number. </p>
<p>
<p>Both AT-MOST-ONE and UNIQUE are examples of "field level constraints."</p>
For example, if a Social Security field within an EMPLOYEE file is both UNIQUE and AT-MOST-ONE; the UNIQUE attribute ensures that the social security number for every employee is different, and AT-MOST-ONE ensures that each employee has only one social security number. </p>
====BINARY-LARGE-OBJECT and CHARACTER-LARGE-OBJECT attributes====
<p>
<p>If a field is defined with the BINARY-LARGE-OBJECT or CHARACTER-LARGE-OBJECT attribute, only the OCCURS attribute can also be assigned to the field.</p>
Both AT-MOST-ONE and UNIQUE are examples of "field level constraints."</p>
<b>Handling NULL support for Large Object data</b>
<p>NULL support for Large object data is handled like the NULL support for string data. If you change Large Object data to null using:</p>
===BINARY-LARGE-OBJECT and CHARACTER-LARGE-OBJECT attributes===
<p>
If a field is defined with the BINARY-LARGE-OBJECT or CHARACTER-LARGE-OBJECT attribute, only the OCCURS and [[MINLOBE attribute|MINLOBE]] attributes can also be assigned to the field.</p>
====Handling NULL support for Large Object data====
<p>
NULL support for Large object data is handled like the NULL support for string data. If you change Large Object data to null using:</p>
<ul>
<ul>
<li>Single quotation marks (' '), Table B stores the null and Table E deletes the former value.</li>
<li>Single quotation marks (' '), Table B stores the null and Table E deletes the former value.</li>
</li>
<li>A trailing an equal sign (= ), the former value is deleted from both Table B and Table E.</li>
<li>A trailing an equal sign (= ), the former value is deleted from both Table B and Table E.</li>
</li>
<li>A source that is zero (0), the former value is deleted from both Table B and Table E.</li>
<li>A source that is zero (0), the former value is deleted from both Table B and Table E.  
</li>
</li>
</ul>
</ul>
====FLOAT attribute====
 
<p>The FLOAT attribute is typically used if the field stores data in floating point representation. For detailed information about the handling of data for fields defined with the FLOAT attribute, refer to the Rocket <var class="product">Model&nbsp;204</var> File Manager's Guide.</p>
===DEFAULT-VALUE attribute===
====FOR EACH VALUE attribute====
The <var>DEFAULT-VALUE</var> attribute specifies the value to use for the field if the record is created and no value has been assigned to the field. The value of the <var>STORE-DEFAULT</var> attribute determines whether the <var>DEFAULT-VALUE</var> value is physically stored on the record or if it is just used as the default value when the field is missing. For more information about <var>DEFAULT VALUE</var>, see the field-design description in [[Field design#DEFAULT-VALUE (DV) attribute|DEFAULT-VALUE (DV) attribute]].
<p>The FOR EACH VALUE attribute maintains a list of all the unique values created for a field. This list can be accessed by using a value loop statement, such as, FOR EACH VALUE, FOR k VALUES, or FIND ALL VALUES.  </p>
 
====INVISIBLE attribute====
===FLOAT attribute===
<p>The INVISIBLE attribute is required if the field is to be used in FILE RECORDS statements. It also can be used for other fields that have the KEY, NUMERIC RANGE, or ORDERED attribute. Such fields can be used for retrievals but cannot be used where the VISIBLE attribute is required.</p>
<p>
<p>An INVISIBLE field cannot be used in an arithmetic expression, as a key in a SORT statement, or in the AUDIT, COUNT OCCURRENCES, DELETE EACH, NOTE, PRINT, SET HEADER, and SET TRAILER statements. An INVISIBLE field also cannot be used in any form of the CHANGE or DELETE statement that is not followed by a fieldname = value pair.     </p>
The <var>FLOAT</var> attribute is typically used if the field stores data in floating point representation. For detailed information about the handling of data for fields defined with the <var>FLOAT</var> attribute, see the file management description of the [[Field design#FLOAT attribute|FLOAT attribute]].</p>
<p>Refer to the Rocket <var class="product">Model&nbsp;204</var> File Manager's Guide for details on the use of INVISIBLE fields in 1NF (First-Normal Form) files.</p>
 
====KEY attribute====
===FOR EACH VALUE attribute===
<p>The KEY attribute specifies that if the field is to be used in FIND statement conditions of the form:      </p>
<p>
<p class="code">fieldname = value  
The FOR EACH VALUE attribute maintains a list of all the unique values created for a field. This list can be accessed by using a value loop statement, such as, FOR EACH VALUE, FOR k VALUES, or FIND ALL VALUES.  </p>
===INVISIBLE attribute===
<p>
The INVISIBLE attribute is required if the field is to be used in FILE RECORDS statements. It also can be used for other fields that have the KEY, NUMERIC RANGE, or ORDERED attribute. Such fields can be used for retrievals but cannot be used where the VISIBLE attribute is required.</p>
<p>
An INVISIBLE field cannot be used in an arithmetic expression, as a key in a SORT statement, or in the AUDIT, COUNT OCCURRENCES, DELETE EACH, NOTE, PRINT, SET HEADER, and SET TRAILER statements. An INVISIBLE field also cannot be used in any form of the CHANGE or DELETE statement that is not followed by a fieldname = value pair.</p>
<p>
See [[Field design#VISIBLE and INVISIBLE attributes|VISIBLE and INVISIBLE attributes]] for further details and also for information about the use of INVISIBLE fields in 1NF (First-Normal Form) files. </p>
 
===KEY attribute===
<p>
The KEY attribute specifies that if the field is to be used in FIND statement conditions of the form:      </p>
<p class="syntax"><span class="term">fieldname</span> = <span class="term">value</span>
</p>
</p>
<p>the Table C index is searched, rather than the data in Table B. Thus, the selection of records based on KEY fields is substantially more efficient than selection based on NON-KEY fields.</p>
<p>
<p>In addition, either the KEY attribute or the ORDERED attribute is required if the field is to be used in FILE RECORDS statements.    </p>
the Table C index is searched, rather than the data in Table B. Thus, the selection of records based on KEY fields is substantially more efficient than selection based on NON-KEY fields.</p>
====LENGTH attribute====
<p>
<p>The LENGTH attribute specifies the preallocated length of a field occurrence in a record. See the discussion on preallocated fields in [[Data Maintenance#Storing values in preallocated fields|Storing values in preallocated fields]].    </p>
In addition, either the KEY attribute or the ORDERED attribute is required if the field is to be used in FILE RECORDS statements.    </p>
====NON-DEFERRABLE attribute====
<p>The NON-DEFERRABLE attribute causes a KEY, NUMERIC RANGE, or ORDERED retrieval field's index entries to be created immediately when the file is open in deferred update mode. All index entries are created immediately when a file is not in deferred update mode. The field cannot be located until its index entry has been created.           </p>
===LENGTH attribute===
====NUMERIC RANGE attribute====
<p>
<p>The NUMERIC RANGE attribute specifies that if the field is used in a retrieval statement that performs a numeric retrieval, the Table C index is searched, rather than the data in Table B. Numeric retrievals based on fields with the NUMERIC RANGE attribute are more efficient than numeric retrievals based on NON-RANGE fields. A NUMERIC RANGE field cannot be multiply occurring.               </p>
The LENGTH attribute specifies the preallocated length of a field occurrence in a record. See the discussion on preallocated fields in [[Data maintenance#Storing values in preallocated fields|Storing values in preallocated fields]].    </p>
====OCCURS attribute====
<p>The OCCURS attribute specifies the number of occurrences of a multiply occurring field that are preallocated in a record. See the discussion on preallocated fields in [[Data Maintenance#Storing values in preallocated fields|Storing values in preallocated fields]].      </p>
===NON-DEFERRABLE attribute===
====ORDERED attribute====
<p>
<p>The ORDERED attribute specifies that the Ordered Index can be searched rather than the data in Table B for most types of retrieval. Thus, the selection of records based on ORDERED fields is substantially more efficient than selection based on NON-ORDERED fields.</p>
The NON-DEFERRABLE attribute causes a KEY, NUMERIC RANGE, or ORDERED retrieval field's index entries to be created immediately when the file is open in deferred update mode. All index entries are created immediately when a file is not in deferred update mode. The field cannot be located until its index entry has been created. </p>  
<p>A field with the ORDERED attribute also produces other efficiencies in User Language. For example, when the IN ORDER option is used on a FOR EACH RECORD statement, an internal sort is not required if the field is ORDERED.</p>
<p>The ORDERED attribute also allows a field to be used with any value loop statement, such as, FIND ALL VALUES, FOR EACH VALUE, and FOR k VALUES. In addition, either the ORDERED attribute or the KEY attribute is required if a field is to be used in FILE RECORDS statements.</p>
===NUMERIC RANGE attribute===
====UNIQUE attribute====
<p>
<p>The UNIQUE attribute automatically enforces a uniqueness constraint on fields; it ensures that a given field name = value pair occurs only in one record in a file. </p>
The NUMERIC RANGE attribute specifies that if the field is used in a retrieval statement that performs a numeric retrieval, the Table C index is searched, rather than the data in Table B. Numeric retrievals based on fields with the NUMERIC RANGE attribute are more efficient than numeric retrievals based on NON-RANGE fields. A NUMERIC RANGE field cannot be multiply occurring. </p>
====VISIBLE attribute====
<p>The VISIBLE attribute is required if the field is to be used in NOTE, PRINT, or SORT statements, or in an arithmetic expression.               </p>
===OCCURS attribute===
====UPDATE attribute====
<p>
<p>The UPDATE attribute indicates the type of update method that is used when a field is changed. </p>
The OCCURS attribute specifies the number of occurrences of a multiply occurring field that are preallocated in a record. See the discussion on preallocated fields in [[Data maintenance#Storing values in preallocated fields|Storing values in preallocated fields]].      </p>  
===ORDERED attribute===
<p>
The ORDERED attribute specifies that the Ordered Index can be searched rather than the data in Table B for most types of retrieval. Thus, the selection of records based on ORDERED fields is substantially more efficient than selection based on NON-ORDERED fields.</p>
<p>
A field with the ORDERED attribute also produces other efficiencies in User Language. For example, when the IN ORDER option is used on a FOR EACH RECORD statement, an internal sort is not required if the field is ORDERED.</p>
<p>
The ORDERED attribute also allows a field to be used with any value loop statement, such as, FIND ALL VALUES, FOR EACH VALUE, and FOR k VALUES. In addition, either the ORDERED attribute or the KEY attribute is required if a field is to be used in FILE RECORDS statements.</p>
 
===STORE-DEFAULT attribute===
See [[#DEFAULT-VALUE attribute|DEFAULT-VALUE attribute]], above.
 
===UNIQUE attribute===
<p>
The UNIQUE attribute automatically enforces a uniqueness constraint on fields; it ensures that a given field name = value pair occurs only in one record in a file. </p>
===VISIBLE attribute===
<p>
The VISIBLE attribute is required if the field is to be used in NOTE, PRINT, or SORT statements, or in an arithmetic expression. </p>
===UPDATE attribute===
<p>
The UPDATE attribute indicates the type of update method that is used when a field is changed. </p>
<ul>
<ul>
<li>If UPDATE IN PLACE is specified, changing the value of a field occurrence does not change its position relative to other occurrences of the same field. The file manager usually specifies UPDATE IN PLACE.</li>
<li>If UPDATE IN PLACE is specified, changing the value of a field occurrence does not change its position relative to other occurrences of the same field. The file manager usually specifies UPDATE IN PLACE.</li>
</li>
<li>If UPDATE AT END is specified, a change in the value of a field occurrence is accomplished by deleting the existing occurrence and adding a new one following the others.</li>
<li>If UPDATE AT END is specified, a change in the value of a field occurrence is accomplished by deleting the existing occurrence and adding a new one following the others.
</li>
</li>
</ul>
</ul>
<p>Refer to [[Operations on Multiply Occurring Fields#UPDATE field attribute|UPDATE field attribute]] for detailed information on the handling of updates based on the type of update method specified.         </p>
<p>
<p>&nbsp;</p>
Refer to [[Processing multiply occurring fields and field groups#UPDATE field attribute|UPDATE field attribute]] for detailed information on the handling of updates based on the type of update method specified. </p>
[[Category:SOUL]]
[[Category:SOUL]]

Latest revision as of 16:16, 24 April 2020

File model feature

The file manager defines fields and assigns attributes to each field, as described in Defining fields manually. The field attributes listed on this page are of interest to the application developer.

You can enforce file-wide constraints on files and fields with two Model 204 file models:

File model Action...
Numeric Validation Causes Model 204 to perform numeric data type validation on fields defined as FLOAT or BINARY.
1NF (First-Normal Form) Ensures that the data within a file conforms to the rules for First-Normal Form.

Use the FILEMODL parameter to set a file model when creating a file.

Field attribute descriptions

AT-MOST-ONE and REPEATABLE attributes

If a field is defined as having the AT-MOST-ONE attribute, Model 204 prevents multiple occurrences of that field in any given record. However, unlike fields with the OCCURS attribute, AT-MOST-ONE fields are not specifically preallocated.

If a field is not defined as AT-MOST-ONE, then it is REPEATABLE.

REPEATABLE is the default except for First-Normal Form files, where AT-MOST-ONE is required on all fields.

AT-MOST-ONE versus UNIQUE attributes

Although the names of the UNIQUE and AT-MOST-ONE attributes sound similar, they have very different meanings:

  • UNIQUE affects the value of the field
  • AT-MOST-ONE affects the number of field occurrences per record

For example, if a Social Security field within an EMPLOYEE file is both UNIQUE and AT-MOST-ONE; the UNIQUE attribute ensures that the social security number for every employee is different, and AT-MOST-ONE ensures that each employee has only one social security number.

Both AT-MOST-ONE and UNIQUE are examples of "field level constraints."

BINARY-LARGE-OBJECT and CHARACTER-LARGE-OBJECT attributes

If a field is defined with the BINARY-LARGE-OBJECT or CHARACTER-LARGE-OBJECT attribute, only the OCCURS and MINLOBE attributes can also be assigned to the field.

Handling NULL support for Large Object data

NULL support for Large object data is handled like the NULL support for string data. If you change Large Object data to null using:

  • Single quotation marks (' '), Table B stores the null and Table E deletes the former value.
  • A trailing an equal sign (= ), the former value is deleted from both Table B and Table E.
  • A source that is zero (0), the former value is deleted from both Table B and Table E.

DEFAULT-VALUE attribute

The DEFAULT-VALUE attribute specifies the value to use for the field if the record is created and no value has been assigned to the field. The value of the STORE-DEFAULT attribute determines whether the DEFAULT-VALUE value is physically stored on the record or if it is just used as the default value when the field is missing. For more information about DEFAULT VALUE, see the field-design description in DEFAULT-VALUE (DV) attribute.

FLOAT attribute

The FLOAT attribute is typically used if the field stores data in floating point representation. For detailed information about the handling of data for fields defined with the FLOAT attribute, see the file management description of the FLOAT attribute.

FOR EACH VALUE attribute

The FOR EACH VALUE attribute maintains a list of all the unique values created for a field. This list can be accessed by using a value loop statement, such as, FOR EACH VALUE, FOR k VALUES, or FIND ALL VALUES.

INVISIBLE attribute

The INVISIBLE attribute is required if the field is to be used in FILE RECORDS statements. It also can be used for other fields that have the KEY, NUMERIC RANGE, or ORDERED attribute. Such fields can be used for retrievals but cannot be used where the VISIBLE attribute is required.

An INVISIBLE field cannot be used in an arithmetic expression, as a key in a SORT statement, or in the AUDIT, COUNT OCCURRENCES, DELETE EACH, NOTE, PRINT, SET HEADER, and SET TRAILER statements. An INVISIBLE field also cannot be used in any form of the CHANGE or DELETE statement that is not followed by a fieldname = value pair.

See VISIBLE and INVISIBLE attributes for further details and also for information about the use of INVISIBLE fields in 1NF (First-Normal Form) files.

KEY attribute

The KEY attribute specifies that if the field is to be used in FIND statement conditions of the form:

fieldname = value

the Table C index is searched, rather than the data in Table B. Thus, the selection of records based on KEY fields is substantially more efficient than selection based on NON-KEY fields.

In addition, either the KEY attribute or the ORDERED attribute is required if the field is to be used in FILE RECORDS statements.

LENGTH attribute

The LENGTH attribute specifies the preallocated length of a field occurrence in a record. See the discussion on preallocated fields in Storing values in preallocated fields.

NON-DEFERRABLE attribute

The NON-DEFERRABLE attribute causes a KEY, NUMERIC RANGE, or ORDERED retrieval field's index entries to be created immediately when the file is open in deferred update mode. All index entries are created immediately when a file is not in deferred update mode. The field cannot be located until its index entry has been created.

NUMERIC RANGE attribute

The NUMERIC RANGE attribute specifies that if the field is used in a retrieval statement that performs a numeric retrieval, the Table C index is searched, rather than the data in Table B. Numeric retrievals based on fields with the NUMERIC RANGE attribute are more efficient than numeric retrievals based on NON-RANGE fields. A NUMERIC RANGE field cannot be multiply occurring.

OCCURS attribute

The OCCURS attribute specifies the number of occurrences of a multiply occurring field that are preallocated in a record. See the discussion on preallocated fields in Storing values in preallocated fields.

ORDERED attribute

The ORDERED attribute specifies that the Ordered Index can be searched rather than the data in Table B for most types of retrieval. Thus, the selection of records based on ORDERED fields is substantially more efficient than selection based on NON-ORDERED fields.

A field with the ORDERED attribute also produces other efficiencies in User Language. For example, when the IN ORDER option is used on a FOR EACH RECORD statement, an internal sort is not required if the field is ORDERED.

The ORDERED attribute also allows a field to be used with any value loop statement, such as, FIND ALL VALUES, FOR EACH VALUE, and FOR k VALUES. In addition, either the ORDERED attribute or the KEY attribute is required if a field is to be used in FILE RECORDS statements.

STORE-DEFAULT attribute

See DEFAULT-VALUE attribute, above.

UNIQUE attribute

The UNIQUE attribute automatically enforces a uniqueness constraint on fields; it ensures that a given field name = value pair occurs only in one record in a file.

VISIBLE attribute

The VISIBLE attribute is required if the field is to be used in NOTE, PRINT, or SORT statements, or in an arithmetic expression.

UPDATE attribute

The UPDATE attribute indicates the type of update method that is used when a field is changed.

  • If UPDATE IN PLACE is specified, changing the value of a field occurrence does not change its position relative to other occurrences of the same field. The file manager usually specifies UPDATE IN PLACE.
  • If UPDATE AT END is specified, a change in the value of a field occurrence is accomplished by deleting the existing occurrence and adding a new one following the others.

Refer to UPDATE field attribute for detailed information on the handling of updates based on the type of update method specified.