DEFINE FIELD command - Revision history

DCameron: /* Specifying a date/time stamp field definition */

2019-02-12T12:28:30Z

Specifying a date/time stamp field definition

← Older revision		Revision as of 12:28, 12 February 2019
Line 429:		Line 429:
	<li>A date/time field cannot be INVISIBLE or UNIQUE.</li>		<li>A date/time field cannot be INVISIBLE or UNIQUE.</li>

	<li>If the date/time stamp field is preallocated, OCCURS cannot be greater than 1.</li>		<li>If the date/time stamp field is preallocated, [[Field_design#Preallocated_fields_.28OCCURS_attribute.29\|OCCURS]] cannot be greater than 1.</li>
	</ul>		</ul>
	<p>		<p>

DCameron: /* Specifying the date/time stamp field name */

2019-02-12T12:26:57Z

Specifying the date/time stamp field name

← Older revision		Revision as of 12:26, 12 February 2019
Line 421:		Line 421:
	The date/time stamp field name you specify is not edited for validity.</p>		The date/time stamp field name you specify is not edited for validity.</p>
	<p>		<p>
	The <var>DTSFN</var> value can be specified in CUST source code so you do not have to change all your jobs to specify the parameter. By default, <var class="product">Model 204</var> does not provide a date/time stamp field name.</p>		The <var>DTSFN</var> value can be specified in [[CUST_module\|CUST]] source code so you do not have to change all your jobs to specify the parameter. By default, <var class="product">Model 204</var> does not provide a date/time stamp field name.</p>

	===Specifying a date/time stamp field definition===		===Specifying a date/time stamp field definition===

DCameron: /* DATETIME fields used as OI CHUNK targets */

2019-02-12T12:23:04Z

DATETIME fields used as OI CHUNK targets

← Older revision		Revision as of 12:23, 12 February 2019
Line 401:		Line 401:
	====DATETIME fields used as OI CHUNK targets====		====DATETIME fields used as OI CHUNK targets====
	<p>		<p>
	A <var>DATETIME</var> field that also has the <var>ORD NUM</var> (<var>ORDERED NUMERIC</var>) attribute can be used as a <var>CHUNK</var> target.		A <var>[[Field_design#DATETIME_.28DT.29_attribute\|DATETIME]]</var> field that also has the <var>ORD NUM</var> (<var>ORDERED NUMERIC</var>) attribute can be used as a <var>CHUNK</var> target.

	Remember that independent of OI chunks, only the 15 leftmost digits of a <var>DATETIME</var> field's 20 digits are stored in the <var>ORD NUM</var> index. When computing the values of OI chunks for a <var>DATETIME</var> target, base the computation on 15 digits, not 20. For example:		Remember that independent of OI chunks, only the 15 leftmost digits of a <var>DATETIME</var> field's 20 digits are stored in the <var>ORD NUM</var> index. When computing the values of OI chunks for a <var>DATETIME</var> target, base the computation on 15 digits, not 20. For example:

DCameron: /* Usage notes */

2019-02-12T12:21:13Z

Usage notes

← Older revision		Revision as of 12:21, 12 February 2019
Line 374:		Line 374:
	<li>OI <var>CHUNK</var> fields are an [[Field design#Automatic fields\|Automatic]] field type. Therefore:		<li>OI <var>CHUNK</var> fields are an [[Field design#Automatic fields\|Automatic]] field type. Therefore:
	<ul>		<ul>
	<li>The <var>CHUNK</var> type is mutually exclusive with all other automatic field types (<var>[[Field_design#CONCATENATION-OF_.28CAT.29_attribute\|CONCATENATION-OF]]</var>, <var>[[Field_design#COUNT-OCCURRENCES-OF_.28CTO.29_attribute\|COUNT-OCCURRENCES-OF]]</var>, <var>CREATE-TIME</var>, <var>CREATE-TIMEUTC</var>, <var>CREATE-USER</var>, <var>UPDATE-TIME</var>, <var>UPDATE-TIMEUTC</var>, <var>UPDATE-USER</var>). </li>		<li>The <var>CHUNK</var> type is mutually exclusive with all other automatic field types (<var>[[Field_design#CONCATENATION-OF_.28CAT.29_attribute\|CONCATENATION-OF]]</var>, <var>[[Field_design#COUNT-OCCURRENCES-OF_.28CTO.29_attribute\|COUNT-OCCURRENCES-OF]]</var>, <var>[[Field_design#CREATE.2A_and_UPDATE.2A_attributes\|CREATE-TIME]]</var>, <var>CREATE-TIMEUTC</var>, <var>CREATE-USER</var>, <var>UPDATE-TIME</var>, <var>UPDATE-TIMEUTC</var>, <var>UPDATE-USER</var>). </li>

	<li>Field values for OI <var>CHUNK</var> fields are set internally as instances of the <var>CHUNK</var> target field are added, deleted, and changed. The value of a <var>CHUNK</var> field is updated at the start of a transaction by Model 204, and it cannot be set explicitly by a program. </li>		<li>Field values for OI <var>CHUNK</var> fields are set internally as instances of the <var>CHUNK</var> target field are added, deleted, and changed. The value of a <var>CHUNK</var> field is updated at the start of a transaction by Model 204, and it cannot be set explicitly by a program. </li>

DCameron: /* Usage notes */

2019-02-12T12:19:50Z

Usage notes

← Older revision		Revision as of 12:19, 12 February 2019
Line 374:		Line 374:
	<li>OI <var>CHUNK</var> fields are an [[Field design#Automatic fields\|Automatic]] field type. Therefore:		<li>OI <var>CHUNK</var> fields are an [[Field design#Automatic fields\|Automatic]] field type. Therefore:
	<ul>		<ul>
	<li>The <var>CHUNK</var> type is mutually exclusive with all other automatic field types (<var>[[Field_design#CONCATENATION-OF_.28CAT.29_attribute\|CONCATENATION-OF]]</var>, <var>COUNT-OCCURRENCES-OF</var>, <var>CREATE-TIME</var>, <var>CREATE-TIMEUTC</var>, <var>CREATE-USER</var>, <var>UPDATE-TIME</var>, <var>UPDATE-TIMEUTC</var>, <var>UPDATE-USER</var>). </li>		<li>The <var>CHUNK</var> type is mutually exclusive with all other automatic field types (<var>[[Field_design#CONCATENATION-OF_.28CAT.29_attribute\|CONCATENATION-OF]]</var>, <var>[[Field_design#COUNT-OCCURRENCES-OF_.28CTO.29_attribute\|COUNT-OCCURRENCES-OF]]</var>, <var>CREATE-TIME</var>, <var>CREATE-TIMEUTC</var>, <var>CREATE-USER</var>, <var>UPDATE-TIME</var>, <var>UPDATE-TIMEUTC</var>, <var>UPDATE-USER</var>). </li>

	<li>Field values for OI <var>CHUNK</var> fields are set internally as instances of the <var>CHUNK</var> target field are added, deleted, and changed. The value of a <var>CHUNK</var> field is updated at the start of a transaction by Model 204, and it cannot be set explicitly by a program. </li>		<li>Field values for OI <var>CHUNK</var> fields are set internally as instances of the <var>CHUNK</var> target field are added, deleted, and changed. The value of a <var>CHUNK</var> field is updated at the start of a transaction by Model 204, and it cannot be set explicitly by a program. </li>

DCameron: /* Usage notes */

2019-02-12T12:17:53Z

Usage notes

← Older revision		Revision as of 12:17, 12 February 2019
Line 374:		Line 374:
	<li>OI <var>CHUNK</var> fields are an [[Field design#Automatic fields\|Automatic]] field type. Therefore:		<li>OI <var>CHUNK</var> fields are an [[Field design#Automatic fields\|Automatic]] field type. Therefore:
	<ul>		<ul>
	<li>The <var>CHUNK</var> type is mutually exclusive with all other automatic field types (<var>CONCATENATION-OF</var>, <var>COUNT-OCCURRENCES-OF</var>, <var>CREATE-TIME</var>, <var>CREATE-TIMEUTC</var>, <var>CREATE-USER</var>, <var>UPDATE-TIME</var>, <var>UPDATE-TIMEUTC</var>, <var>UPDATE-USER</var>). </li>		<li>The <var>CHUNK</var> type is mutually exclusive with all other automatic field types (<var>[[Field_design#CONCATENATION-OF_.28CAT.29_attribute\|CONCATENATION-OF]]</var>, <var>COUNT-OCCURRENCES-OF</var>, <var>CREATE-TIME</var>, <var>CREATE-TIMEUTC</var>, <var>CREATE-USER</var>, <var>UPDATE-TIME</var>, <var>UPDATE-TIMEUTC</var>, <var>UPDATE-USER</var>). </li>

	<li>Field values for OI <var>CHUNK</var> fields are set internally as instances of the <var>CHUNK</var> target field are added, deleted, and changed. The value of a <var>CHUNK</var> field is updated at the start of a transaction by Model 204, and it cannot be set explicitly by a program. </li>		<li>Field values for OI <var>CHUNK</var> fields are set internally as instances of the <var>CHUNK</var> target field are added, deleted, and changed. The value of a <var>CHUNK</var> field is updated at the start of a transaction by Model 204, and it cannot be set explicitly by a program. </li>

DCameron: /* Usage notes */

2019-02-12T12:16:06Z

Usage notes

← Older revision		Revision as of 12:16, 12 February 2019
Line 364:		Line 364:
	===Usage notes===		===Usage notes===
	<ul>		<ul>
	<li>OI <var>CHUNK</var> fields must be <var>ORDERED NUMERIC INVISIBLE</var>. </li>		<li>OI <var>CHUNK</var> fields must be <var>ORDERED NUMERIC [[Field_design#VISIBLE_and_INVISIBLE_attributes\|INVISIBLE]]</var>. </li>

	<li>OI <var>CHUNK</var> fields can only be defined for <var>ORDERED NUMERIC VISIBLE</var> fields. </li>		<li>OI <var>CHUNK</var> fields can only be defined for <var>ORDERED NUMERIC VISIBLE</var> fields. </li>

DCameron: /* Usage notes */

2019-02-12T12:13:04Z

Usage notes

← Older revision		Revision as of 12:13, 12 February 2019
Line 320:		Line 320:
	If a field is defined as ORDERED without specifying the type of tree to create, the default depends on whether the field is [[Field_design#STRING_attribute\|STRING]], [[Field_design#BINARY_attribute\|BINARY]], or FLOAT. If STRING, an ORDERED CHARACTER tree is defined. If FLOAT or BINARY, an ORDERED NUMERIC tree is defined.</p>		If a field is defined as ORDERED without specifying the type of tree to create, the default depends on whether the field is [[Field_design#STRING_attribute\|STRING]], [[Field_design#BINARY_attribute\|BINARY]], or FLOAT. If STRING, an ORDERED CHARACTER tree is defined. If FLOAT or BINARY, an ORDERED NUMERIC tree is defined.</p>
	<p>		<p>
	The UNIQUE attribute specifies that there can be only one occurrence of a unique field in the file. Multiple occurrences are not allowed.</p>		The [[Field_design#UNIQUE_and_NON-UNIQUE_attributes\|UNIQUE]] attribute specifies that there can be only one occurrence of a unique field in the file. Multiple occurrences are not allowed.</p>
	<p>For a detailed discussion of field attributes, see [[Field design]].</p>		<p>For a detailed discussion of field attributes, see [[Field design]].</p>

DCameron: /* Usage notes */

2019-02-12T12:11:32Z

Usage notes

← Older revision		Revision as of 12:11, 12 February 2019
Line 318:		Line 318:
	The default ordering for a field is NON-ORDERED. Ordered Index attributes do not apply for a NON-ORDERED field.</p>		The default ordering for a field is NON-ORDERED. Ordered Index attributes do not apply for a NON-ORDERED field.</p>
	<p>		<p>
	If a field is defined as ORDERED without specifying the type of tree to create, the default depends on whether the field is [[Field_design#STRING_attribute\|STRING]], BINARY, or FLOAT. If STRING, an ORDERED CHARACTER tree is defined. If FLOAT or BINARY, an ORDERED NUMERIC tree is defined.</p>		If a field is defined as ORDERED without specifying the type of tree to create, the default depends on whether the field is [[Field_design#STRING_attribute\|STRING]], [[Field_design#BINARY_attribute\|BINARY]], or FLOAT. If STRING, an ORDERED CHARACTER tree is defined. If FLOAT or BINARY, an ORDERED NUMERIC tree is defined.</p>
	<p>		<p>
	The UNIQUE attribute specifies that there can be only one occurrence of a unique field in the file. Multiple occurrences are not allowed.</p>		The UNIQUE attribute specifies that there can be only one occurrence of a unique field in the file. Multiple occurrences are not allowed.</p>

DCameron: /* Usage notes */

2019-02-12T12:10:33Z

Usage notes

← Older revision		Revision as of 12:10, 12 February 2019
Line 318:		Line 318:
	The default ordering for a field is NON-ORDERED. Ordered Index attributes do not apply for a NON-ORDERED field.</p>		The default ordering for a field is NON-ORDERED. Ordered Index attributes do not apply for a NON-ORDERED field.</p>
	<p>		<p>
	If a field is defined as ORDERED without specifying the type of tree to create, the default depends on whether the field is STRING, BINARY, or FLOAT. If STRING, an ORDERED CHARACTER tree is defined. If FLOAT or BINARY, an ORDERED NUMERIC tree is defined.</p>		If a field is defined as ORDERED without specifying the type of tree to create, the default depends on whether the field is [[Field_design#STRING_attribute\|STRING]], BINARY, or FLOAT. If STRING, an ORDERED CHARACTER tree is defined. If FLOAT or BINARY, an ORDERED NUMERIC tree is defined.</p>
	<p>		<p>
	The UNIQUE attribute specifies that there can be only one occurrence of a unique field in the file. Multiple occurrences are not allowed.</p>		The UNIQUE attribute specifies that there can be only one occurrence of a unique field in the file. Multiple occurrences are not allowed.</p>