Archives of the TeradataForum

Message Posted: Wed, 03 Apr 2002 @ 21:50:03 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Narayan,

If you're going to complain about NCR documentation, congratulations on your new career. However, over the years, I've seen a lot of application programs that may generate error reports. Many times, the programmer wrote out the headings for the error report in the initialization part of the program, and then, began processing input data. If there were no errors, the report still printed, headings only, no detail entries. This may be the same with the "ghost" tables. They create the table in anticipation of an error, but there are none. Yes, they could clean up an empty table (they could generate the table only when an error was found); yes, they could fail the job if constraint violations are found, eliminating the need for an additional table; but, they don't. The whole process is iffy, especially for those unaware of the constraint violation table(s). And, as Rob Grothaus pointed out, RI will not be present on tables COPYed from one environment to another, and REVALIDATE REFERENCES FOR (Teradata Archive/Recovery Reference, rel 06.07.00, pp 4-60) must be run when a child or parent is restored

Two things become obvious: 1) The Teradata approach to RI needs work and will most likely evolve as we go on. 2) As all rows in the error tables have to be resolved for the constraint to be completely effective, it would be best, if possible, to create a new table with the constraint as part of the definition, and load from the old. This could possibly eliminate a lot of work.

On a final note, unless the _0 table is deleted, additional "ghost" tables will be created and increase in number (i.e. _01, _02, _03...) as each new constraint is added.

KC

p.s. When dealing with an empty table, why not DROP/CREATE with the constraint as part of the initial definition rather than CREATE/ALTER?

	<Prev	Next>		<<First	<Prev	Next>	Last>>