Explanation of Teradata Connector Log Errors
Problem
We found some errors in log files when analyzing Teradata scripts with IBM Manta Data Lineage. Could you provide detailed information as to what these errors mean?
Solution
The table below describes the error messages you can find in Manta Data Lineage connector log files (e.g.,
teradataDdlDataflowMasterScenario_Teradata.properties.log
and teradataBteqDataflowMasterScenario_Teradata.properties.log
).
First, some common terms need to be explained.
- Parsing
- Processing SQL input into machine-readable format, understanding the meaning of statements and their parts
- Resolving
- Assigning meaning to identifiers used in the statements, determining what objects they refer to (e.g., that in
"SELECT * from table1"
, table1 means a table called "table1" in the database "myDB", and * means columns "column1" and "column2")
- Assigning meaning to identifiers used in the statements, determining what objects they refer to (e.g., that in
- Guess/guessing
- Estimating the meaning of an identifier based on its use and surrounding context when it cannot be resolved to any known database object
Error/warning |
Pattern |
Explanation |
---|---|---|
E |
Error parsing … |
The script cannot be processed at all; this happens when the script structure is significantly broken (unpaired quotation marks or brackets, missing semicolons, etc.) |
E |
No viable alternative at … |
The parser found an invalid (or valid, but unsupported) command or structure; the command was skipped and processing continued at the next command |
E |
|
|
E |
Found multiple columns of the same name … |
Invalid input—a reference to a column is ambiguous |
W |
DEDUCTION—Creating deduced … |
A database object (i.e., a column or table) which is not found in the database dictionary was referenced in the script; the parser used a deduction, that is, based on script context, it guessed what type of object it might be; this can lead to other errors in further processing (e.g., the parser does not know the exact count and names of the table’s columns) |
E |
Unexpected column name count |
When the script tried to name columns, the count of names did not equal the count of columns; this can be caused by invalid input or bad deduction |
E |
Wrong column count for operand … |
The counts of columns in a set operation were not equal; this can be caused by invalid input or bad deduction |
E |
Column position differs for column … |
Positions of the source columns in the statement did not equal the positions in the target; this can be caused by input that uses one object name for more purposes or by bad deduction |
W |
Too many actual parameters when calling … |
The counts of current and declared subprogram parameters were not equal; this can be caused by invalid input or bad deduction |
W |
DEDUCTION—Deducing a NULL literal for index … in operand … |
Since the counts of operand columns in the set operation did not match, it was necessary to use deduction for some columns |
E |
Too many columns found in scalar subquery resultset … |
Invalid input—the scalar expression returns more than one column |
E |
Unable to parse column position |
Invalid input when referencing the column by position |
W |
DEDUCTION—The new deduced subprogram … cannot be added to database … |
Deduction caused the names of two subprograms to collide (e.g., it is the ABC procedure, but the ABC function is called in the script) |
W |
DEDUCTION—Using subprogram … with non-matching database (the reference did not mention any database, implying current database) for … |
The parser did not find the subprogram of a given (not fully qualified) name in the data dictionary of the current database; however, it found a subprogram with the same name in another database referenced in the script before, so it used that one |
W |
DEDUCTION—Using table … for unqualified name … |
The parser did not find the referenced table in the data dictionary of the current database; however, it found a table with the same name in another database referenced in the script before, so it used that one |
W |
DEDUCTION—Using table … for unqualified table or alias name … while no such name was found in query sources |
The referenced table is not used in the FROM clause of the query; however, it exists in the data dictionary of the current database, so the existing table was used |
W |
DEDUCTION—Using local variable … |
Invalid input—the referenced variable is not valid in the current line in the script; however, a definition of a variable with the same name was found in the script context, so the parser used that one |
W |
Table with no columns … |
The dataflow generator got a table with no columns in its input; probably the deduction of the table was successful, but the deduction of its columns was not |
W |
Empty source … |
The source or target of a dataflow was an empty column list, so it is not possible to create the dataflow; this can be caused by invalid input or bad deduction |
W |
Different sizes … |
During the creation of the 1:1 dataflow between columns, the counts of source and target columns were not equal |