What this error looks like
SQL0569N Authorization ID "WSCOMUSR" does not uniquely
identify a user, a group or a role in the system.
If WebSphere Commerce gets this error (or it may look similar for other applications), it looks like this:
2011-03-04 11:37:18.076,, com.ibm.commerce.context.content.ant.tasks.UpdateWorkspacesTableTask::performTask(), S1 CWXBR0001E: A generic runtime system exception occured. The exception is: "com.ibm.db2.jcc.a.SqlException: DB2 SQL Error: SQLCODE=-569, SQLSTATE=56092, SQLERRMC=WSCOMUSR, DRIVER=4.3.111
Does this error mean the command didn’t work
Yes – note the “N” on the end.
Common Causes
This error is usually encountered on a grant statement. DB2 does not require that you specify whether you are granting to a user, a role, or a group, so DB2 must determine which one you mean when you do the grant statement. Therefore, if you have a user and a group with exactly the same name, db2 will not be able to determine which one you mean. In that case, the grant statement fails with this error.
The sneaky thing about this error is that you might test something and not encounter it, but then encounter it if you happen to have a user id and a group with the same name. There was one WebSphere Commerce fixpack that granted some permissions without specifying “user” or “group”, and therefore we discovered this error on one system when we had successfully installed the fixpack on other servers.
Common Solutions
The first solution here is to get in the habit of always specifying “user” or “group” when you write grant statements. Instead of:
db2 grant select on orders to my_user db2 grant select on orders to my_group db2 grant select on orders to my_role
Use this:
db2 grant select on orders to user my_user db2 grant select on orders to group my_group db2 grant select on orders to role my_role
The other solution is to simply make it so that you don’t have a user and a group with the same name – this could be easy or hard depending on your security strategy. In the cases I’ve seen this, normally someone has accidentally created a group as a user or vice-versa, and when they correct it, they don’t drop the incorrect one. If you insist on having a security strategy that includes users and groups with the same name, then this solution is obviously not an option.
