Field design - Revision history

Dme: /* BLOB and CLOB compatibility with other attributes */

2020-04-24T16:22:25Z

BLOB and CLOB compatibility with other attributes

← Older revision		Revision as of 16:22, 24 April 2020
Line 474:		Line 474:
	====BLOB and CLOB compatibility with other attributes====		====BLOB and CLOB compatibility with other attributes====
	<p>		<p>
	See the ~~table in <var>~~[[~~DEFINE FIELD command\|DEFINE FIELD~~]]~~</var>~~ for ~~a list of~~ attributes that are not allowed with <var>BLOB</var> or <var>CLOB</var>. Use of conflicting attributes produces the following message:</p>		See the [[Field attribute combinations]] page for the attributes that are not allowed with <var>BLOB</var> or <var>CLOB</var>. Use of conflicting attributes produces the following message:</p>
	<p class="code">M204.0411: ~~CONFLICTING ATTRIBUTES~~: ([BLOB \| CLOB]) <var class="term">attribute2</var>		<p class="code">M204.0411: Conflicting attributes: ([BLOB \| CLOB]) and <var class="term">attribute2</var>
	</p>		</p>

DCameron: /* ORDERED CHARACTER fields */

2019-02-12T12:06:11Z

ORDERED CHARACTER fields

← Older revision		Revision as of 12:06, 12 February 2019
Line 76:		Line 76:
	<p>		<p>
	ORDERED CHARACTER fields use the standard EBCDIC collating sequence. If a field is ORDERED CHARACTER, all values of the field are stored in the Ordered Index in EBCDIC collating sequence order.</p>		ORDERED CHARACTER fields use the standard EBCDIC collating sequence. If a field is ORDERED CHARACTER, all values of the field are stored in the Ordered Index in EBCDIC collating sequence order.</p>

	=====ORDERED NUMERIC fields=====		=====ORDERED NUMERIC fields=====
	<p>		<p>

ELowell: /* Handling Large Object data */

2019-01-23T22:50:48Z

Handling Large Object data

← Older revision		Revision as of 22:50, 23 January 2019
Line 467:		Line 467:
	<ul>		<ul>
	<li>The new CLOB field must be populated, from the STRING field, using a SOUL program and the universal buffer.</li>		<li>The new CLOB field must be populated, from the STRING field, using a SOUL program and the universal buffer.</li>
	<li>Or, if using Fast/Unload, a STRING field can be converted to a CLOB during UAI/LAI. See [[Fast/Unload_BLOB/CLOB_processing_considerations#NEW_statement_option_for_Lobs\|~~New~~ statement option for Lobs]] for more details.</li>		<li>Or, if using Fast/Unload, a STRING field can be converted to a CLOB during UAI/LAI. See [[Fast/Unload_BLOB/CLOB_processing_considerations#NEW_statement_option_for_Lobs\|NEW statement option for Lobs]] for more details.</li>
	</ul>		</ul>
	</li>		</li>

ELowell: /* Handling Large Object data */

2019-01-23T22:48:44Z

Handling Large Object data

← Older revision		Revision as of 22:48, 23 January 2019
Line 467:		Line 467:
	<ul>		<ul>
	<li>The new CLOB field must be populated, from the STRING field, using a SOUL program and the universal buffer.</li>		<li>The new CLOB field must be populated, from the STRING field, using a SOUL program and the universal buffer.</li>
	<li>Or, if using Fast/Unload, a STRING field can be converted to a CLOB during UAI/LAI. See [[Fast/Unload_BLOB/CLOB_processing_considerations#NEW_statement_option_for_Lobs\|New statement option for Lobs]] for more details.</li>		<li>Or, if using Fast/Unload, a STRING field can be converted to a CLOB during UAI/LAI. See [[Fast/Unload_BLOB/CLOB_processing_considerations#NEW_statement_option_for_Lobs\|New statement option for Lobs]] for more details.</li>
			</ul>
	</li>		</li>
	</ul>		</ul>

ELowell: /* Handling Large Object data */

2019-01-23T22:47:02Z

Handling Large Object data

← Older revision		Revision as of 22:47, 23 January 2019
Line 464:		Line 464:

	<li>Field-level security is supported.</li>		<li>Field-level security is supported.</li>
			<li>A string field cannot be converted to a CLOB via PAI unload followed by FLOD/FILELOAD.
			<ul>
			<li>The new CLOB field must be populated, from the STRING field, using a SOUL program and the universal buffer.</li>
			<li>Or, if using Fast/Unload, a STRING field can be converted to a CLOB during UAI/LAI. See [[Fast/Unload_BLOB/CLOB_processing_considerations#NEW_statement_option_for_Lobs\|New statement option for Lobs]] for more details.</li>
			</li>
	</ul>		</ul>

JAL: /* Multiple CHUNK fields */ add `s`

2018-04-10T16:17:20Z

Multiple CHUNK fields: add <var>s

← Older revision		Revision as of 16:17, 10 April 2018
Line 183:		Line 183:
	=====Multiple CHUNK fields=====		=====Multiple CHUNK fields=====
	<p>		<p>
	To get even better performance, you could define multiple CHUNK fields for a target field:		To get even better performance, you could define multiple <var>CHUNK</var> fields for a target field:
	</p>		</p>
	<p class="syntax">DEFINE FIELD YYYYMMDD WITH ORDERED NUMERIC		<p class="syntax">DEFINE FIELD YYYYMMDD WITH ORDERED NUMERIC
Line 191:		Line 191:
	</p>		</p>
	<p>		<p>
	The OI chunk size for a CHUNK field must be a greater-than-1 integral multiple of all smaller OI chunk sizes for the same target field. For example, specifying "7" as the first CHUNK size in the above example would be invalid because 100 is not an integral multiple of 7.</p>		The OI chunk size for a <var>CHUNK</var> field must be a greater-than-1 integral multiple of all smaller OI chunk sizes for the same target field. For example, specifying "7" as the first <var>CHUNK</var> size in the above example would be invalid because 100 is not an integral multiple of 7.</p>
	<p>		<p>
	Note that you could reference the CHUNK fields directly in non-updating statements, as shown in this example:</p>		Note that you could reference the <var>CHUNK</var> fields directly in non-updating statements, as shown in this example:</p>

	<p class="code">fd to %recset		<p class="code">fd to %recset
Line 200:		Line 200:
	</p>		</p>
	<p>		<p>
	In any case, the number and size of the CHUNK fields allows you to trade off the overhead of doing updates against the efficiency of doing range finds. </p>		In any case, the number and size of the <var>CHUNK</var> fields allows you to trade off the overhead of doing updates against the efficiency of doing range finds. </p>

	====Choosing between ORDERED and FRV====		====Choosing between ORDERED and FRV====
	<p>		<p>

JAL: /* CHUNK attribute */ add `s`

2018-04-10T16:16:12Z

CHUNK attribute: add <var>s

ELowell: /* ON FIELD CONSTRAINT CONFLICT (ON FCC) unit */

2018-03-15T22:56:36Z

ON FIELD CONSTRAINT CONFLICT (ON FCC) unit

← Older revision		Revision as of 22:56, 15 March 2018
Line 1,344:		Line 1,344:
	The $UPDSTAT function takes no arguments. </p>		The $UPDSTAT function takes no arguments. </p>
	<p>		<p>
	See information about the [[#AT-MOST-ONE ~~and REPEATABLE attributes~~\|AT-MOST-ONE and REPEATABLE attributes]].</p>		See information about the [[#AT-MOST-ONE.2C_REPEATABLE.2C_and_EXACTLY-ONE_attributes\|AT-MOST-ONE and REPEATABLE attributes]].</p>
	<b>UNIQUE and ORDERED fields</b>		<b>UNIQUE and ORDERED fields</b>
	<p>		<p>

JAL: misc formatting

2017-11-28T21:36:39Z

misc formatting

Show changes

JAL: misc formatting

2017-11-27T18:39:59Z

misc formatting

Show changes

← Older revision		Revision as of 16:16, 10 April 2018
Line 150:		Line 150:

	=====CHUNK attribute=====		=====CHUNK attribute=====
	However, as of Model 204 version 7.5, you can improve the efficiency of data range retrieval on ORDERED NUMERIC fields by defining the fields with the <var>[[DEFINE FIELD command#CHUNK attribute\|CHUNK]]</var> attribute.		However, as of Model 204 version 7.5, you can improve the efficiency of data range retrieval on <var>ORDERED NUMERIC</var> fields by defining the fields with the <var>[[DEFINE FIELD command#CHUNK attribute\|CHUNK]]</var> attribute.

	The CHUNK attribute defines a subrange ("OI chunk") of the Ordered Index data range, so the desired data can be found with fewer scans of the Ordered Index entries.		The <var>CHUNK</var> attribute defines a subrange ("OI chunk") of the Ordered Index data range, so the desired data can be found with fewer scans of the Ordered Index entries.

	CHUNK fields are ~~AUTOMATIC~~ fields and therefore require that FILEORG X'100' be set for the file.		<var>CHUNK</var> fields are automatic fields and therefore require that FILEORG X'100' be set for the file.

	The CHUNK attribute is followed by a number, defining the size of the OI chunk, and then FOR <var class="term">chunkTargetFieldName</var>, where <var class="term">chunkTargetFieldName</var> is the existing ORDERED NUMERIC field from which you want to retrieve data in OI chunks.		The <var>CHUNK</var> attribute is followed by a number, defining the size of the OI chunk, and then FOR <var class="term">chunkTargetFieldName</var>, where <var class="term">chunkTargetFieldName</var> is the existing <var>ORDERED NUMERIC</var> field from which you want to retrieve data in OI chunks.

	So, to illustrate:		So, to illustrate:
Line 163:		Line 163:
	</p>		</p>
	<p>		<p>
	A CHUNK field is automatically maintained based on updates to the target (FOR) field (here, YYYYMMDD). The stored value is the value of the target field rounded down to the CHUNK size. So, for example, if you stored a value of 20121225 into YYYYMMDD, the underlying code would automatically store the value 20121200 into YYYYMM. Similarly, if you stored 20121203 into YYYYMMDD, a 20121200 value would also be stored into YYYYMM.		A <var>CHUNK</var> field is automatically maintained based on updates to the target (FOR) field (here, YYYYMMDD). The stored value is the value of the target field rounded down to the CHUNK size. So, for example, if you stored a value of 20121225 into YYYYMMDD, the underlying code would automatically store the value 20121200 into YYYYMM. Similarly, if you stored 20121203 into YYYYMMDD, a 20121200 value would also be stored into YYYYMM.
	</p>		</p>
	<p>		<p>
	When doing a range find, Model 204 decomposes the find into range finds based on the CHUNK field and the target field.		When doing a range find, Model 204 decomposes the find into range finds based on the <var>CHUNK</var> field and the target field.
	So, for example, a find for values between 20121211 and 20130205 would be decomposed into a find for:		So, for example, a find for values between 20121211 and 20130205 would be decomposed into a find for:
	</p>		</p>
	<ul>		<ul>
	<li>YYYYMMDD between 20121211 and 20121299 (ignoring for the moment issues with non-integer values and demonstrating that CHUNK doesn't really know or care if the field is a date)</li>		<li>YYYYMMDD between 20121211 and 20121299 (ignoring for the moment issues with non-integer values and demonstrating that <var>CHUNK</var> doesn't really know or care if the field is a date)</li>

	<li>OR YYYYMM between 20130100 and 20130100 (or more precisely, exactly equal to 20130100)</li>		<li>OR YYYYMM between 20130100 and 20130100 (or more precisely, exactly equal to 20130100)</li>
Line 180:		Line 180:
	Results would often be much better than that. For example, it probably would not be atypical for a date range to land on month boundaries, resulting in improvements closer to a factor of 30. And, as the range got bigger and bigger, more and more of the range processing would occur on the CHUNK field, with additional improvement in processing.		Results would often be much better than that. For example, it probably would not be atypical for a date range to land on month boundaries, resulting in improvements closer to a factor of 30. And, as the range got bigger and bigger, more and more of the range processing would occur on the CHUNK field, with additional improvement in processing.
	</p>		</p>

	=====Multiple CHUNK fields=====		=====Multiple CHUNK fields=====
	<p>		<p>

Field design - Revision history

Dme: /* BLOB and CLOB compatibility with other attributes */

DCameron: /* ORDERED CHARACTER fields */

ELowell: /* Handling Large Object data */

ELowell: /* Handling Large Object data */

ELowell: /* Handling Large Object data */

JAL: /* Multiple CHUNK fields */ add s

JAL: /* CHUNK attribute */ add s

ELowell: /* ON FIELD CONSTRAINT CONFLICT (ON FCC) unit */

JAL: misc formatting

JAL: misc formatting

JAL: /* Multiple CHUNK fields */ add `s`

JAL: /* CHUNK attribute */ add `s`