SQL/MX 3.2 Management Manual (H06.25+, J06.14+)

For more information about other input file considerations, including using a field qualifier, field
delimiter, row delimiter, or record delimiter, see the SQL/MX Reference Manual.
Output File Considerations for import
Rows in the parsing error log file must look exactly like the corresponding row in the input file.
However, rows in the execution error log file may not look like the corresponding row in the input
file. Four notable cases are:
1. The format of numbers may be changed. Example: 123456.7 in the original input file may
appear as 1.234567E+05 in the error log file.
2. The value of some floating-point numbers may not be exactly the same (though very close).
This is due to an internal conversion to binary format and then back to floating point ASCII
format for logging to the error log file.
3. Any string which includes the field delimiter, the row delimiter, or the field-qualifier character
may appear differently. For example, if the field qualifier is a double quote character ("):
• Use a double-quote(""") <in the original input file> may come out as
"Use a double-quote(")" <in the error log file>
4. If the format file said to skip say column 1 of each row of the original input file, then that data
will be missing completely in the execution error log file. Example:
• "Data for a manager", 378456, Comm. Dept, 125 <in the input file> may
come out as 378456, Comm. Dept, 125 <in the error log file>
NOTE: The leading comma (Field Delimiter character) indicates that the first field is missing. If
the format file said to skip a column in the middle of each row, that would be indicated by
consecutive Field Delimiter characters in execution error log rows. If the input file has fixed width
columns rather than using field delimiters, then rows in the execution error log file would contain
all NullValue characters (as specified in the format, file or space by default) for any skipped
columns.
Although the appearance of such rows is different in the execution error log than in the input file,
these rows in the error log can still be used to import to the destination table without requiring you
to fix these appearance differences. The real problem that caused the row to get an execution
error would need to be fixed by you, but these appearance differences do not require fixing by
you before the row can be imported. Such appearance differences do not affect the column values
in the destination table. The only possible exception to this would be if you considered the miniscule
change in the value of a floating point number to be significant.
Other import Features
import automatically turns auditing off for all partitions of an empty table without indexes.
Auditing is turned back on after the import operation completes or if it fails for any reason. This
enables import to take advantage of fast loading techniques and to avoid TMF transaction issues.
Turning off auditing for a table invalidates online dumps. After the import operation completes,
you must take a new TMF online dump for all partitions on the table. For more information, see
the “Running import on Empty Tables” (page 195).
To improve the performance of the fasting load technique, import turns off the audit attribute for
the entire table at the start of the operation and turns it back on when the operation ends. If another
import operation is attempted on the same table while an import operation with the fast loading
technique is being performed, the second operation fails with a concurrent access error. For more
information, see the SQL/MX Reference Manual.
If the table is not empty or has dependent indexes, import continues with the normal load
operation using TMF transactions.
For more information, see the SQL/MX Reference Manual.
194 Reorganizing SQL/MX Tables and Maintaining Data