Given a particular job name, from the Datastage repository can I query(from Administrator or otherwise) to find out what is the source and target table names used in the Job.
Assumption is that I use only one source and target table and I use the Dynamic RDBMS stage for both.
(If not familiar with Dynamic RDBMS stage can also give solution considering I was using ODBC stage)
Thanks.
SGT
Querying for Source and Target Table Names
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
And, if you've used job parameters for table names, this can be quite a messy query!
The table name is a property of the passive stage's input or output link. So, given a job name, you need to determine a list of that job's stage names (from DSStages Where JobName = 'name'). Then you need to determine the link names connected to stages (from DSLinks joined to those rows in DSStages). Then you need to determine which links connect to which table names (from DSProperties joined to those rows from DSLinks). If they're parameters, you then have the parameter name(s) and have to join also to DSParameters and from there back to DSProperties to get the table names. Enjoy! Or get MetaStage, when it does the work for you.
The table name is a property of the passive stage's input or output link. So, given a job name, you need to determine a list of that job's stage names (from DSStages Where JobName = 'name'). Then you need to determine the link names connected to stages (from DSLinks joined to those rows in DSStages). Then you need to determine which links connect to which table names (from DSProperties joined to those rows from DSLinks). If they're parameters, you then have the parameter name(s) and have to join also to DSParameters and from there back to DSProperties to get the table names. Enjoy! Or get MetaStage, when it does the work for you.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.