The rules for performing data linkage on BLOB-type columns are as follows:

• To perform data linkage on BLOB-type columns, specify ALL in the RECOVERY operand in HiRDB's table definition. For details about HiRDB table definition, see the manual HiRDB Version 9 SQL Reference.
• Datareplicator uses the BLOB column definition lengths, not the actual lengths of the BLOB data, to perform processing (including buffer allocation). For this reason, use for the definition lengths of BLOB columns values that are as close as possible to the actual data lengths.
• A definition error will occur if an attempt is made to extract a BLOB-type column whose definition length is 2 GB or greater or whose definition length was omitted during table creation (in which case HiRDB assumes 2 GB as the definition length). We recommend that you use for data linkage BLOB-type columns whose definition length is a maximum of several megabytes.
  If a BLOB-type column has a definition length of 2 GB or greater but its actual data is small, you can perform data linkage on such a column by specifying the HDE_BIN_COL_MAXLEN environment variable in the source Datareplicator without having to re-define the table. For details about the HDE_BIN_COL_MAXLEN environment variable, see the following subsections:
  
  • 2.4.1 Environment variables for a source Datareplicator (UNIX)
  • 2.8.1 Environment variables for a source Datareplicator (Windows)
  • 6.4.3(4) Notes about the HDE_BIN_COL_MAXLEN environment variable
• BLOB-type source columns cannot be used as mapping keys.
• Data linkage is not performed on a BLOB-type column that is subject to processing by an HiRDB utility even if the utility's processing outputs update logs. This is because Datareplicator does not recognize data in BLOB-type columns updated by utilities. Note that the results of utility execution on BLOB-type columns are not imported into the target database.
• For unimported BLOB-type data in the target Datareplicator, update data is output in the following format:
  *BLOB(data-length)*
  

The rules for performing data linkage on BINARY-type columns are as follows:

• Taking into account performance and memory requirements, we recommend that you perform data linkage on BINARY-type columns whose definition length is no more than 10 MB.
• BINARY-type source columns cannot be used as mapping keys.
• For unimported BINARY-type data in the target Datareplicator, update data is output in the following format:
  *BINARY(data-length)*
  

You can perform backward deletion updating on BLOB and BINARY types if you specify BACKWARD_CUTOFF_UPDATE in the pd_rpl_func_control operand in HiRDB's system common definition. For details about backward deletion updating on BLOB and BINARY types, see the HiRDB Version 9 UAP Development Guide.

The following limitations apply to backward deletion updating for BLOB and BINARY types:

• Data cannot be imported to merge tables.
• Data cannot be imported to chronologically-ordered information tables.
• Column data editing UOC routines cannot be used.
• Send data UOC routines cannot be used.

Notes about specifying the pd_rpl_func_control operand:

If you will not be performing backward deletion updating on BLOB or BINARY types, do not specify BACKWARD_CUTOFF_UPDATE in the pd_rpl_func_control operand in HiRDB's system common definition.

Before you change the BACKWARD_CUTOFF_UPDA specification in the pd_rpl_func_control operand, make sure that all update logs have been imported. If the pd_rpl_func_control operand is changed while there is an unimported update log, problems such as unmatched SQL statement execution counts between the source and target databases occur.