[{{ load { field-name[{{,field-name }} ...]|* }
  from update-information-name
  { to[{ timestamp|sqlconvopt1|sqlconvopt2 }]
     [ authorization-identifier.]table-identifier[ check { not_null_unique|unique|none }][ with lock ]|by 'uoc-name' }
  }} ...]

• load { field-name[{{,field-name }} ...]|* }
  Specify the fields in the update information so that they correspond to the table subject to import processing. It is essential that the field name for the mapping key corresponds to the target table's column containing the mapping key.
  Specify in HiRDB's pd_max_access_tables operand a value that is equal to or greater than the number of specified load statements. If the pd_max_access_tables operand value is less than the number of specified load statements, HiRDB issues the KFPA11931-E message and an error results. For details about the pd_max_access_tables operand, see the manual HiRDB Version 9 System Definition.
  

  field-name

  Specify each field name corresponding to a target table column. Specify these field names sequentially from left to right as they are to be arranged in the target table. You can specify a maximum of 4000 field names. The number of specified field names must match the number of columns in the target table.

  *

  If the asterisk (*) is specified, Datareplicator ignores the update information field definition for the corresponding update information (Datareplicator also ignores const, column data editing UOC function identifier, and nocodecnv).

  All fields in the update information are imported into the target table in exactly the same order.

• from update-information-name
  ~ <symbolic name of 1-8 characters>
  Specify the update information name that is to be subject to import processing. This name must have been specified in the extraction definition.
  
• to[{ timestamp|sqlconvopt1|sqlconvopt2 }][authorization identifier.]table identifier
  [check {not_null_unique|unique|none}][with lock]|by 'uoc-name'
  Define the authorization identifier and table identifier of the target table or a UOC name name'. For details about the authorization identifier and table identifier, see the manual HiRDB Version 9 SQL Reference.
  If you specify the target table's table identifier, you can also specify the following options:
  
  • Whether time-ordered information is to be acquired
  • Whether a merge table is to be created
  • Whether a uniqueness check is to be performed
  • Whether the LOCK TABLE statement is to be issued to the target table

  timestamp

  Specify this operand to collect time-ordered information. When timestamp is specified, Datareplicator handles the information specified in the load clause as a time-ordered information storage table.

  You cannot specify timestamp for a table containing a repetition column; if specified, a definition analysis error occurs and import processing with this data linkage identifier will stop.

  sqlconvopt1|sqlconvopt2

  Specify one of these values to create a merge table that enables addition and deletion as well as update processing. To specify these values, the target table must satisfy all the following conditions:

  1. A unique index must be defined for some or all of the mapping key columns.
  2. A unique index cannot be defined for a non-mapping key column.
  3. The target table must not be a time-ordered information table.
  4. The mapping key will not be updated.
  The following table shows the SQL statement execution and the difference between the two values:
  

  SQL statement	sqlconvopt1	sqlconvopt2
  INSERT resulting in a duplicate key	Executes UPDATE instead.	Executes UPDATE instead.
  UPDATE resulting in no corresponding row	Executes INSERT instead.	Executes INSERT instead.
  DELETE	Deletes the corresponding row.	If there is a corresponding row, Datareplicator sets the NULL value in the target column that is not a mapping key column and for which the CONST clause is not specified, and then executes UPDATE. If there is no corresponding row, Datareplicator ignores the SQL statement.
  PURGE	Deletes all rows.	Deletes all rows.

  Notes on creating a merge table

  1. To create a merge table, you must specify sqlconvopt1 or sqlconvopt2. The difference between sqlconvopt1 and sqlconvopt2 is in the handling of DELETE data. sqlconvopt1 handles a DELETE as row deletion, while sqlconvopt2 handles it as null value updating. Columns that are not specified in a format statement's const clause are subject to this null value updating.
  2. When you specify creation of a merge table, an SQL statement is issued twice. If there is a large volume of conversion processing, import processing might be adversely affected.
  3. When a column data editing UOC routine is used, it is called twice, immediately prior to issuance of an SQL statement before and after conversion. The UOC routine is also called when DELETE is executed with sqlconvopt2 specified; in this case, the data value is the null value.

  authorization-identifier

  Specify the authorization identifier for the target table. If you have specified timestamp, specify the authorization identifier for the time-ordered information storage table. If you omit the authorization identifier, Datareplicator assumes the authorization identifier specified in the import system definition.

  table-identifier

  Specify the target table's table identifier. If you have specified timestamp, specify the table identifier of the time-ordered information storage table.

  check {not_null_unique|unique|none}

  Specify the condition for performing a uniqueness check on the mapping key column. The table below provides the details of uniqueness checking. When this clause is specified, Datareplicator performs the uniqueness check according to the specified value, regardless of the mapping_key_check operand value in the import environment definition.

  When this clause is omitted, Datareplicator performs the check based on the value of the mapping_key_check operand.

  Note that Datareplicator does not perform a uniqueness check on a table for which the timestamp option has been specified.

  When you use the merge table creation option, we recommend that you specify not_null_unique.

  Table 5-18 Details of uniqueness checking

  Check item	Description
  Index type	The index type must be one of the following: Unique index Unique cluster index Primary index Primary cluster index
  Index component column	There must be only mapping key component columns.

  not_null_unique

  Check the target table to confirm that the index satisfying the conditions described in Table 5-18 Details of uniqueness checking has been defined and its index component columns have the NOT NULL attribute.

  unique

  Check the target table to confirm that the index satisfying the conditions described in Table 5-18 Details of uniqueness checking has been defined. Because this option does not check the NULL value, you need to use a tool such as a user program that updates the source database to ensure the uniqueness of the data.

  none

  Do not perform a uniqueness check. You need to use a tool such as a user program that updates the source database to ensure the uniqueness of the data.

  The target Datareplicator's processing depends on whether the mapping_key_check operand or the check clause is specified.

  The following table shows examples of the mapping_key_check operand (not_null_unique specified) and the target Datareplicator's processing.

  Example	Datareplicator's processing
  load * from t1 to T1 check not_null_unique	Datareplicator performs the not_null_unique check.
  load * from t1 to T1 check none load * from t1 to T1	Datareplicator does not perform checking.

  The following table shows examples in which the mapping_key_check operand is omitted (specification of the check clause takes effect) and the target Datareplicator's processing.

  Example	Datareplicator's processing
  load * from t1 to T1 check not_null_unique	Datareplicator performs the not_null_unique check.
  load * from t1 to T1 check none	Datareplicator does not perform checking.
  load * from t1 to T1	Datareplicator performs the not_null_unique check.

  with lock

  Specify this clause to execute import processing after issuing the LOCK TABLE statement for the table specified in the load statement. This clause is applicable only to import processing on HiRDB. If it is specified for import processing on a target other than HiRDB, this clause is ignored.

  Specify the with lock clause in the following cases:

  Import processing is to be executed on a shared table that has been created in HiRDB's shared RDAREA (required^#)

  #: Omitting this clause results in an SQL execution error.

  Overhead for locking is to be reduced during import processing (optional)

  The following table describes the operation in the event that the LOCK TABLE statement results in an error.

  Table 5-19 Operation in the event that the LOCK TABLE statement results in an error

  SQLCODE	When the skip_sqlcode operand is omitted in the import environment definition	When the skip_sqlcode operand is specified in the import environment definition
  -770, -911, -722, -723	Datareplicator rolls back the executing transaction and retries the same transaction up to two times. If the second retry does not correct the error, Datareplicator outputs to the unimported information file the KFRB03034-E message and the LOCK TABLE statement resulting in the error, and then terminates import processing.	Datareplicator skips the LOCK TABLE statement and resumes import processing in the status in which no LOCK TABLE statement has been issued. The type of information to be output depends on the sqlerr_skip_info operand specified in the import environment definition (if output or msgoutput is specified, Datareplicator outputs the KFRB03043-W message).
  Other	Datareplicator outputs to the unimported information file the KFRB03034-E message and the LOCK TABLE statement resulting in the error, and then terminates import processing.

  Notes:

  When you specify the with lock clause, we recommend that you store a single target table per RDAREA.

  This clause is not applicable to the import process configuration shown below because deadlock might occur:

  
  

  If the target table is a shared table, the target table and any non-target tables must be stored in different shared RDAREAs; otherwise, such a non-target table cannot be referenced or updated while an import transaction is accessing the shared table.

  by 'uoc-name'

  ~ <pathname of 1-64 bytes>
  To execute import processing using a user-created routine (UOC), specify the absolute pathname for that routine. You cannot specify its filename without the path. When you specify the by clause, you cannot specify a literal field in the load clause.