Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Federated database access

2 views
Skip to first unread message

Damir

unread,
May 8, 2008, 11:11:51 AM5/8/08
to
Hello,
I have a strange problem with federated access between two DB2 databases,
both on AIX 5, both instances V9.1 (FP02).

For the sake of this post, the two DB2 databases are named:
1. "live"
2. "archive"

When I create the user mapping on the "live" database:

db2 "create user mapping for myuser server my_archive_server options
(remote_authid 'myuser', remote_password 'mypwd')"

and then connect to the "live" database as user "myuser" and try to access
any of the nicknames that point to the tables in the "archive" database, I
get the following error:

SQL0551N "The ODBC authid " does not have the privilege to perform
operation "unknown " on object "unknown ". SQLSTATE=42501

I gave proper (read) priviledges to the tables in the "archive" database, as
well as to the nicknames in the "live" database.
And yet I only managed to get rid of the above error by giving the user
myuser direct DBADM priviledge on the "archive" database?!?

Also (this is without user "myuser" having the DBADM priviledge on the
"archive" db): trying to connect directly to the "archive" database as user
"myuser" (using pwd "mypwd") works OK (connect priviledge given), and I can
select from the tables in that database (select priviledges are given)
without problems.

So, why is the federated access not working with the above mentioned user
mapping (unless given the DBADM priviledge), when the username and password
are OK for connecting to the "archive" db?

Any ideas would be much appreciated!

Regards,
Damir


Lew

unread,
May 9, 2008, 10:06:05 AM5/9/08
to
did you grant access to the nickname to user myuser

Damir

unread,
May 12, 2008, 9:02:09 AM5/12/08
to

> did you grant access to the nickname to user myuser

I did, and it didn't help.
As I said - when I give user myuser the direct DBADM priviledge on the
"archive" database, all is working well (except for the fact that user
myuser can update/delete data in the "archive" database, which is not
desirable), which means that permissions on the "live" database are OK...

0 new messages