DSXchange

I am trying to import ODBC table defs. I choose the DSN, enter my username and password, and I get the following error. Surprisingly, another team member is able to import with my username and password successfully on his DataStage. I am completely puzzled.

Please advise.

You sure you dont have your caps lock on ?

Check this POST.

It sure is a puzzle.
May be your forgot your password but your team member still remembers it

narasimha wrote:It sure is a puzzle.
May be your forgot your password but your team member still remembers it

I sure wish you were right but unfortunately you are not.

I_Server_Whale wrote:Check this POST.

I checked out all 3 pages of it, but I couldn't find anything that would resolve my issue.

Since my team member is able to log in, it would mean that the uvodbc.config and .odbc.ini files on the server have the correct entries.

I also installed the ODBC drivers on my terminal but to no success.

Is there anything else I need to do on my terminal? And by the way, the database I am trying to import table defs from is in Netezza.

I was kidding buddy, an exact search on "BCI Error" gave 86 matches.
May be someone else had a similar issue.

Edited to add: Check a similar if not sameissue with odbc and Netezza

The ODBC driver is configured on your Unix server. The only way DS works different from two separate clients is because of DataStage USERID permissions. The database driver doesn't care which database userid it uses. If you saw a discrepancy with your database userid functionality on someone elses machine, have them connect to DataStage as YOU. Then try importing with your database userid/password.

kcbland wrote:The only way DS works different from two separate clients is because of DataStage USERID permissions.

You were absolutely right. Thanks a lot. I am now working on resolving the differences between the permissions of the two USERIDs.

just4geeks wrote:

kcbland wrote:The only way DS works different from two separate clients is because of DataStage USERID permissions.

I have changed the perms such that they are the are the same now. Still, the connection doesn't go through. Any ideas.

Can your other team mate able to make it up with your datastage use id/pwd?
Same way, what happens if you try with the other members login in you PC?

Okay, have the person who can import metadata come over to your PC and login into DataStage as themself. Then try to import metadata. I'll be a monkeys uncle if it doesn't work. The import of metadata is a SERVER side activity. The only thing that matters is the userid trying to use DataStage, because it's that userid who is used to do things.

kcbland wrote:Okay, have the person who can import metadata come over to your PC and login into DataStage as themself. Then try to import metadata. I'll be a monkeys uncle if it doesn't work. The import of metadata is a SERVER side activity. The only thing that matters is the userid trying to use DataStage, because it's that userid who is used to do things.

You are right.
If the other person logs on my DS as himself and uses either his database id or my database id, he can retrieve the table definitions. However, if he logs in with my Datastage ID, and uses his database id or my database id to import the table defs, the errors occurs.

As I said earlier, I changed my permissions to what he has. I am still unable to connect. Please advise.

You have clearly missed at least one vital aspect of those permissions.

ray.wurlod wrote:You have clearly missed at least one vital aspect of those permissions.

here is how it looks when I run the id command at the prompt.

me
uid=5753(xxxxxxx) gid=1000(bbb) groups=1000(aaa),100(users),326(dsadm),330(dstage),327(dsops),328(dsdev),329(dsman),5541(project)


The other person
uid=525(yyyyyyy) gid=1000(bbb) groups=1000(aaa),326(dsadm),330(dstage),327(dsops),328(dsdev),329(dsman),5541(project)