SQL/MX 3.2.1 Management Manual (H06.26+, J06.15+)

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 198).
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.
Recommended Practices for Improving import Performance
This subsection describes recommended practices for improving the performance of import
operations on SQL/MX tables:
• “Running import on Empty Tables” (page 198)
• “Running import on Populated Tables” (page 198)
• “Managing Partitions to Improve import Performance” (page 199)
• “Managing Constraints to Improve import Performance” (page 199)
• “Managing Indexes to Improve import Performance” (page 200)
Using import to Load SQL/MX Tables 197