Guys
In one of the posts here, it's mentioned that we don't need to promote Table Definitions to other environment if we are just need to run the job in that environment rather changing it.
Is that true ? Doesn't DataStage look for Table Defs in the repository when it runs the job ? On the other hand, It makes me think otherwise...Since we are compiling it and making it as a package it does not need them again if we don't want to change what is built ?
Very Happy New Year 2006 !
Thanks
Don't we need Table Defs to run the DSJob ?
Moderators: chulett, rschirm, roy
Technically, the information stored under Table Definitions is not needed at all. You can build and run and maintain jobs without ever having generated any metadata, instead typing it in by hand. Over and over again.
Not saying that it isn't a good idea to have and use them, just not absolutely needed.
![Shocked :shock:](./images/smilies/icon_eek.gif)
Not saying that it isn't a good idea to have and use them, just not absolutely needed.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Aaarrggh!!
The whole rationale behind being able to import table definitions then load them into jobs, fully or partially, using mouse clicks is that they remain untouched by human hands, and therefore error-free. This maximizes your chances of creating a working job first time.
While the other posters are technically correct, they are not, repeat not, advocating manual creation of table definitions.
Arnd's point, that what you've built into your job design isn't actually needed to run the job is true.
However, if you're using MetaStage to perform lineage analysis on your production systems, you do need to move the table definitions to the production environment, because MetaStage uses these (and the links to them from job designs) to perform that analysis.
![Exclamation :!:](./images/smilies/icon_exclaim.gif)
![Exclamation :!:](./images/smilies/icon_exclaim.gif)
![Exclamation :!:](./images/smilies/icon_exclaim.gif)
The whole rationale behind being able to import table definitions then load them into jobs, fully or partially, using mouse clicks is that they remain untouched by human hands, and therefore error-free. This maximizes your chances of creating a working job first time.
While the other posters are technically correct, they are not, repeat not, advocating manual creation of table definitions.
Arnd's point, that what you've built into your job design isn't actually needed to run the job is true.
However, if you're using MetaStage to perform lineage analysis on your production systems, you do need to move the table definitions to the production environment, because MetaStage uses these (and the links to them from job designs) to perform that analysis.
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.
![Laughing :lol:](./images/smilies/icon_lol.gif)
No need to revert back to your Primal Scream therapy days, Ray.
![Shocked :shock:](./images/smilies/icon_eek.gif)
I thought it was very clear that none of us here were advocating the non-use of metadata. Just trying to be thoroughly anal, make some additional points about metadata usage and do our own versions of a Full Wurlod. Perhaps we should leave that to the professional.
![Wink :wink:](./images/smilies/icon_wink.gif)
Nice to know about the MetaStage linkage, makes sense.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Hi,
I think that assuming you loaded the tables definitions in the columns page and that relates to the same table/s you want to see in the table name it should show regardless of using parameters for table name/s.
then again I have no means to test it right now![Sad :(](./images/smilies/icon_sad.gif)
Anyone able to shed some light on this?
I think that assuming you loaded the tables definitions in the columns page and that relates to the same table/s you want to see in the table name it should show regardless of using parameters for table name/s.
then again I have no means to test it right now
![Sad :(](./images/smilies/icon_sad.gif)
Anyone able to shed some light on this?
Roy R.
Time is money but when you don't have money time is all you can afford.
Search before posting:)
Join the DataStagers team effort at:
http://www.worldcommunitygrid.org
![Image](http://www.worldcommunitygrid.org/images/logo.gif)
Time is money but when you don't have money time is all you can afford.
Search before posting:)
Join the DataStagers team effort at:
http://www.worldcommunitygrid.org
![Image](http://www.worldcommunitygrid.org/images/logo.gif)
-
- Premium Member
- Posts: 892
- Joined: Thu Oct 16, 2003 5:18 am
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
MetaStage (and Manager Usage Analysis) don't work if table names are job parameters. It seems happy enough if user ID, password and even schema are job parameter references, however.
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.