Hi All,
We are using Enterprise for our some of the Data Stage Loading Jobs.
We have roles in Teradata and granted same to Load User, which is getting used to run jobs.
But we are getting an error "The table not in writtable stage". Does it becuase of roles, As job is running fine if we directly grant right to Load User.
Thanks
Raj
Enterprise with Teradata
Moderators: chulett, rschirm, roy
Welcome to Dsxchange!!! :D
Check whether the table has the load previlage for that user. Also try to load from command prompt and check the state of the table. So that you can handle it in database prespective.
Check whether the table has the load previlage for that user. Also try to load from command prompt and check the state of the table. So that you can handle it in database prespective.
Impossible doesn't mean 'it is not possible' actually means... 'NOBODY HAS DONE IT SO FAR'
It having all the privilges to run job. We hv tested with grant insert/update/delete right directly to user without using ROLES ,The enterprise job is working fine. But same is not working with Roles (Its not working if we giving I/U/D to role and granting role to User.kumar_s wrote:Welcome to Dsxchange!!! :D
Check whether the table has the load previlage for that user. Also try to load from command prompt and check the state of the table. So that you can handle it in database prespective.
-
- Premium Member
- Posts: 209
- Joined: Fri Jan 09, 2004 1:14 pm
- Location: Toronto, Canada
- Contact:
Hi RAJARORA,
Which stage are you using, the TD Enterprise or TD MLoad stage?
There are some issues with the Enterprise stage needing to create a temporary table in the same database as the target table in order to get parallelism happening. If your user id doesn't have create privileges, the enterprise stage will fail.
Does this sound like what is happening? Perhaps the role doesn't have create, but the user id does?
Rob W.
Which stage are you using, the TD Enterprise or TD MLoad stage?
There are some issues with the Enterprise stage needing to create a temporary table in the same database as the target table in order to get parallelism happening. If your user id doesn't have create privileges, the enterprise stage will fail.
Does this sound like what is happening? Perhaps the role doesn't have create, but the user id does?
Rob W.
Rob Wierdsma
Toronto, Canada
bartonbishop.com
Toronto, Canada
bartonbishop.com
I have seen the problem that Rob is pointing out result in the following error message:
"TeraUtils:DB Call Failure(success check) Info = 0, Code = 3524, Message = The user does not have CREATE TABLE access to database: dbanme", which can be resolved with an additional parameter: WORKDB under "Additional connection options" in the enterprise stage.
But the "The table not in writtable stage" error is due to an Enterprise stage defect.
NCR Team response is that if the following query returns no rows, then the table is considered not writable from Teradata Enterprise stage point of view:
Quote:
select * from dbc.userrights where databasename = 'dbname'
and (tablename = 'xxxxxx' or tablename = 'all') and accessright = 'I'
Which means if you grant privileges on the database level or grant roles insert rights, and then assign a particular id that role, it is not good enough.
The suggested workaround is to grant insert access directly to the userid, or to grant insert access to all tables in the database using the ALL keyword.
This defect is tracked under ECASE 87666 and a patch is available. Contact support for the same.
"TeraUtils:DB Call Failure(success check) Info = 0, Code = 3524, Message = The user does not have CREATE TABLE access to database: dbanme", which can be resolved with an additional parameter: WORKDB under "Additional connection options" in the enterprise stage.
But the "The table not in writtable stage" error is due to an Enterprise stage defect.
NCR Team response is that if the following query returns no rows, then the table is considered not writable from Teradata Enterprise stage point of view:
Quote:
select * from dbc.userrights where databasename = 'dbname'
and (tablename = 'xxxxxx' or tablename = 'all') and accessright = 'I'
Which means if you grant privileges on the database level or grant roles insert rights, and then assign a particular id that role, it is not good enough.
The suggested workaround is to grant insert access directly to the userid, or to grant insert access to all tables in the database using the ALL keyword.
This defect is tracked under ECASE 87666 and a patch is available. Contact support for the same.
Last edited by yakiku on Mon Sep 18, 2006 10:41 am, edited 1 time in total.