Page 1 of 1
Dynamic RDMS
Posted: Thu Jun 10, 2010 4:53 am
by Milin16
Hi All,
I wanted to create a volatile table in a datastage job using a database stage. I am aware that Dynamic RDMS can be used to create the table but I am not aware how do we call Teradata in it. This is because in the drop down list of DBMS type there is no interface of Teradata.
Job structure:
Dynamic RDMS - -> Trfm - -> File
I am not aware how do we use 'Job Parameter' for the same.
It would be great if you could help me on the same..
Posted: Thu Jun 10, 2010 6:01 am
by chulett
Welcome.
The dropdown in the DRS stage will show you what databases are support. If there is no native support for your database of choice then you may be able to fall back to ODBC (which should be listed) as long as you have the ODBC drivers for your database. Me, I have no clue if ODBC based Teradata drivers ship with the product. I'd also be curious what exact 7.x version of DataStage you have as the capabilities of the DRS stage increased over time and were pretty limited when it first came out.
What stage would you normally be using for Teradata? Pretty much any DB stage should allow creation of a target table, that's not something unique to the DRS stage. Hence the question.
Posted: Thu Jun 10, 2010 6:40 am
by Milin16
Thanks for a prompt reply.. Actually in Teradata I am using Teradata Enterprise stage and TD Multiload both doesnot have an option to create a volatile table which is my requirement.
TD Enterprise- Creates permanent table.
TD Multiload stage- Have no option of creation of table.
So I am not sure which stage will help me create a volatile table which is session specific. I read somewhere in the forum that DRS can be used to create volatile tables so was trying to use it..
Thanks,
Milin
Posted: Thu Jun 10, 2010 6:45 am
by chulett
Do those stages support user-defined DDL for table creation? If so, I would imagine that you could simply adjust the syntax to create a volatile / temp table. Not having used either of those, I have no clue what they can or cannot do. What about ODBC? Is that an option for you here?
Those kind of tables can be... problematical... in an ETL tool as sometimes people misunderstand the scope of their lives and what constitutes a 'session'.