Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Wed, 22 Oct 2003 @ 20:13:18 GMT


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


Subj:   Re: References
 
From:   Dieter Noeth

Chris Coffing wrote:

  The reason is that we need to have all the DDL information and have found that the CreatText field is sometimes NULL or only has a portion of the DDL.  


How can the CreateText column hold only a portion of the DDL? An oversized CreateText would IMHO result in error 3850/3851?


  In regards to tables, it captures the alter statement in the creattext field and so we do not have the table DDL for our use.  


How do you extract the table DDL? Using SHOW TABLE? There still may be a 3661.


  (We use this DDL information in our Configuration Management and Recovery solutions.)  


  We use the Delta-Processing to determine what has changed on a daily basis. The data dictionary is a real-time storage area and does not capture change.  


  We can determine what changes have occurred in our warehouse on a daily basis and research these changes based on every time we pull the system. (This is daily at this time)  


  We want to get the Stored Proc's so we can determine if these procedures will break or if they are already broken. It has worked rather well.  


How do you extract the SP DDL, it's stored as a part of the SP "table", so you'll have to use SHOW PROCEDURE, but what if it's created with NO SPL?

[snip]


  Here is one more interesting value proposition.  


  I have experienced when views are created using a "SELECT *" that these views will break when a table column is either altered or a column is removed (same as altered I know) except the view will not break if a column is added to the table.  


  The view however will not show the newly added column until the view is replaced using the "SELECT *" method, or any other method for that matter.  


At least it's Standard SQL behaviour :-)


  Since this is the case for views, we use the object reference information to determine what we need to touch after we make changes to the tables in the warehouse.  


  We have several internal customers that have certain security rights assigned to them based on views. This means we may have 5 or more views that do the same thing with a slight difference for security concerns. When changes are made to the tables, we must determine what we must adjust across the entire warehouse before we deploy the changes.  


It's always good to have a good documentation and a kind of Change Control...


Dieter



     
  <Prev Next>   <<First <Prev Next> Last>>  
 
 
 
 
 
 
 
 
  
  Top Home Privacy Feedback  
 
 
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 15 Jun 2023