Scribd
Upload
34 views1 page

Reformat Before Tableload

The reformats that are being done before table loads should not be removed even though they appear to be doing nothing. Removing the reformats can destabilize the loads and is not a best practice. The reformats help adapt the data from the graph to the output table, which may have different needs than the graph. It is also better for performance to use fixed length fields in the graph rather than delimited fields.

Uploaded by

Sravya Reddy
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
34 views1 page

Reformat Before Tableload

The reformats that are being done before table loads should not be removed even though they appear to be doing nothing. Removing the reformats can destabilize the loads and is not a best practice. The reformats help adapt the data from the graph to the output table, which may have different needs than the graph. It is also better for performance to use fixed length fields in the graph rather than delimited fields.

Uploaded by

Sravya Reddy
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 1

Reformat Before Table Load

ITtoolbox as adapted from Abinitio-L discussion group Summary: Is it always necessary to have to reformat before table load? In one of the graphs I am loading, there are more than 30 tables that we are reformatting before table loads and these reformats are not doing anything, just straight moves. Can we just remove them? I removed them and it ran fine. My target DB is DB2. Full Article: Disclaimer: Contents are not reviewed for correctness and are not endorsed or recommended by ITtoolbox or any vendor. Popular Q&A contents include summarized information from ITtoolbox Abinitio-L discussion unless otherwise noted. Adapted from response by Remediator on 8/16/2008 Don't remove them. This is a standard best practice; if you remove them it can destabilize your loads. The reformat's output adapts to the output table, and the reformat's input adapts to the graph. It is never a good practice to assume that the graph and the output table are always compatible. The output table and the database always have different needs than the graph. Besides that, this tells me that you are probably using delimited fields in your graph, which is a worst practice for performance. You should be using fixed length in your graph for best performance, and then adapt it to delimited for output. Keep the reformats - you are inviting significant problems by removing them.
9/16/2008 By ITtoolbox Popular Q&A Team for

You might also like