Dropped Tables - Parallel Transporter

Teradata® Parallel Transporter Reference - 20.00

Deployment
VantageCloud
VantageCore
Edition
IntelliFlex
Lake
Enterprise
VMware
Product
Parallel Transporter
Release Number
20.00
Published
October 2023
ft:locale
en-US
ft:lastEdition
2023-12-06
dita:mapPath
mjn1691132485167.ditamap
dita:ditavalPath
obe1474387269547.ditaval
dita:id
ogv1478610452101
lifecycle
latest
Product Category
Teradata Tools and Utilities

Some tables are created during the execution of a job, and others must be created by the user before the job begins. With the Update operator, target tables must exist on the database when the Update operator job is executed. The log table is created automatically when you run the Update job script. Error tables and work tables are created by the database.

Error tables are dropped by the Update operator during the cleanup phase if no errors are detected during the acquisition phase or the application phase. The work table is dropped by the Update operator during the cleanup phase if no errors are detected during the acquisition phase or the application phase. The log table is dropped by the Update operator after the job completes successfully.

If a job terminates abnormally, then the log, error, and work tables may not be dropped, depending on where in the job the termination occurs. If you want to restart the job from scratch, you must manually drop these tables by running a BTEQ script.

Care must be taken if the target tables are manually dropped using a BTEQ script. If something goes wrong with an Update operator job, and you drop the target table manually and then try to rerun the job, you may lose the original data. This is because all rows are actually placed into worktables and they remain there until the Update operator job reaches the application phase, at which time the rows are copied to the real target tables.