28

When I execute this SQL:

USE ASPState
GO
IF NOT EXISTS(SELECT * FROM sys.sysusers WHERE NAME = 'R2Server\AAOUser')
CREATE USER [R2Server\AAOUser] FOR LOGIN [R2Server\AAOUser];
GO

I get the following error:

The login already has an account under a different user name.

How do I know what this different user name is for my login account?

29

This means that the login [R2Server\AAOUser] is already mapped to a user in that database. Or, in other words, another database user is using this login. You can see what database user is using your login with the following query:

use YourDB
go
SELECT su.name as DatabaseUser
FROM sys.sysusers su
join sys.syslogins sl on sl.sid = su.sid
where sl.name = 'test' -- login

PS: a version of the script that doesn't use the compatibility views:

Select sp.name as LoginName, sp.type_desc as LoginType,
    dp.name as DBUser, dp.type_desc as UserType
from sys.server_principals sp
join sys.database_principals dp on dp.sid = sp.sid
where sp.name = 'test' -- your login
  • Ok, I see the value dbo being displayed. Strange, I don't remember that I have use the dbo for my account R2Server\AAOUser. Wondering what I should do next. – Jack Feb 22 '13 at 9:06
  • 4
    Have you created the database using that login to connect to the server? If yes, then you're the db owner of it and don't need to create another user. You're already set. – Marian Feb 22 '13 at 9:16
  • Actually, I used the command aspnet_regsql -E -S .\MSSQLSERVER_R2 -ssadd to create the ASPState database. I think probably, I am already set, even though, I even don't realize it in the first place. – Jack Feb 22 '13 at 9:18
  • Guess what: "-E -> Authenticate with current Windows credentials." :-) – Marian Feb 22 '13 at 9:29
  • 4
    I would use sys.server_principals and sys.database_principals. sysusers and syslogins are only there for backward compatibility. – Aaron Bertrand Feb 22 '13 at 14:23
3

It's a 'metadata thing' ...

Sometimes the database user gets 'corrupted' over the course of whatever is going on in that DB. (I've seen similar behavior if the DB gets restored, and the roles in the restored copy differ from what the one you overlaid contained. This is why I tried below, which fixed the problem for me.)

  1. Open up the Login properties in SSMS --> (Security | Logins | failing UserID | Properties | User Mapping). You'll probably see the DB's already checked and has Roles assigned (like perfectly normal).

  2. Note the permissions on the DB giving the error, just for reference.

  3. Uncheck that DB and save the login.
  4. Now re-run your query to add the Login/Role into the target DB. It should work just fine.
  • 2
    when I get to step 3, I get: Cannot drop the user 'dbo'. (Microsoft SQL Server, Error: 15150) – bkwdesign Dec 21 '17 at 19:10
  • I also got the Cannot drop the user 'dbo'. error message. I ran this script, which removed the problematic user mapping and fixed the issue: USE DATABASE_NAME; ALTER AUTHORIZATION ON DATABASE::DATABASE_NAME TO [sa]. For more information this is the source I used: blog.sql-assistance.com/index.php/cannot-drop-the-user-dbo – SherlockSpreadsheets Mar 1 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.