none
The login already has an account under a different user name. (Microsoft SQL Server, Error: 15063)

    Question

  •  

    Hi,

     

    I have two databases xxx and yyy.

    I added a new user to xxx named as "Admin". It ownes some schemas.

    Afterwards I added a new user to yyy named as "Admin". It ownes the same schemas.

    Then I pressed ok button, got the error:" The login already has an account under a different user name. (Microsoft SQL Server, Error: 15063)".

     

     

    Could you please give me some advice?

     

    Thanks

    Tuesday, June 24, 2008 7:56 PM

Answers

  •  

      I would recommend looking at the SIDs on both the server scope (sys.server_principals) and the database scope (sys.database_principals) to help you correlate the name of the user mapped to the login.

      There are two likely possibilities for the root cause of this problem:

    1)      You restored a DB that contained already users mapped in it that are conflicting with your application.

    2)      The model DB was modified and the user was created there. In this case every time a new DB is created the new user will be mapped as well.

     

      BTW. I would recommend using T-SQL script directly instead of using the SQL Server Management Studio while debugging this scenario. SSMS is not resilient to this kind of problems  and it will probably fail to execute the operations you need.

     

      -Raul Garcia

      SDE/T

      SQL Server Engine

    Tuesday, June 24, 2008 11:48 PM
    Moderator

All replies

  • You are trying to add the login twice, when it already exists.  When you create the new user, you can select a pre-existing login by browsing logins and not entering user name, or you can start all over and:

     

    Create a new database login:

     

    Go to Security folder in Mgmt Studio.

     

    Right-click new login.  Under Login name type the domain name\user name

    Make sure Windows authentication is selected

    Go to user mappings on the left, and select the checkbox for your databases.

     

    At the bottom where it says: database role membership, select db_datareader.

     

     

      And, it is better to change your account to something more discreet, as it is not good practice to name an account Admin, as it is a security risk, since it is such a widely known name for an account.

    Tuesday, June 24, 2008 8:10 PM
  • I did select a pre-existing login by browsing logins then type a user name.

    Can you please look at my steps:

     

    Steps:

     

    1)  Expand database xxx node, go to security.

    2)  Right click users then select "New User".

    3)  Browse logins and select a pre-existing login which is domain name\user name(LT\Admin).

    4) Type a user name "Admin" and click "OK".

     

        Utill now everything is okay.

     

    5)  Expand database yyy node, go to security.

    6)  Right click users then select "New User".

    7)  Browse logins and select a pre-existing login which is domain name\user name(LT\Admin).

    8) Type a user name "Admin" and click "OK".

     

        Then an error appears as the thread title.

    Tuesday, June 24, 2008 8:46 PM
  • Try going to Security...Logins at the server level.  Double click on login LT\Admin.  Under user mapping, click on database yyy, and change the user mapped to the login to Admin.  There is already a user mapped to the login for database yyy, so that is why you are getting the error.

     

    Tuesday, June 24, 2008 9:00 PM
  •  

    The default User for yyy is "dbo". I clicked on the tiny map box for yyy and replaceed user "dbo" with "LT\Admin".

    Still wrong.

     

    Tuesday, June 24, 2008 9:32 PM
  •  

    I thought you were mapping Admin to LT\Admin, no?  Try just Admin.
    Tuesday, June 24, 2008 9:55 PM
  • Did you restore the yyy database from another SQL instance or server?

     

    Run the following in SSMS while logged on to the yyy database:

     

    Code Snippet
    sp_change_users_login 'report'

     

     

     

    If you get an output from it, you can remap the database user Admin to the Server Login LT\Admin by running:

     

    Code Snippet

    sp_change_users_login 'update_one', 'LT\Admin', 'Admin'

     

     

    sp_change_users_login (Transact-SQL)

    Q274188 PRB: "Troubleshooting Orphaned Users" Topic in Books Online is Incomplete

     

     

    Tuesday, June 24, 2008 10:39 PM
    Moderator
  •  

      I would recommend looking at the SIDs on both the server scope (sys.server_principals) and the database scope (sys.database_principals) to help you correlate the name of the user mapped to the login.

      There are two likely possibilities for the root cause of this problem:

    1)      You restored a DB that contained already users mapped in it that are conflicting with your application.

    2)      The model DB was modified and the user was created there. In this case every time a new DB is created the new user will be mapped as well.

     

      BTW. I would recommend using T-SQL script directly instead of using the SQL Server Management Studio while debugging this scenario. SSMS is not resilient to this kind of problems  and it will probably fail to execute the operations you need.

     

      -Raul Garcia

      SDE/T

      SQL Server Engine

    Tuesday, June 24, 2008 11:48 PM
    Moderator
  • I had a similar issue with the same error message when adding Active Directoy users. I was equally baffeled because sp_change_users_login 'Report' showed no orphans and syssysusers didn't show that user either. Additionally, the user I was trying to add truely did not exist in the database--and was an Active Dirctory user. I even went as far as deleting the login and readding it to both SQL Server and the database via CREATE USER. With all tests, I was using the CREATE USER syntax when I got the error. However, I could add the user successfully using SSMS.

    I was able to get rid of the error by changing my query session to log in as the actual SA.

     I re-ran CREATE USER and the user added just fine. What was puzzling was I got the error message when using my personal AD account which had sysadmin priviledges. Additionally, I could add other users with my personal login--just not this one. I'm curious to see if I can duplicate this issue by creating a sql user with sysadmin privs and retrying the user addition.

    But for now, all my issues went away when I used the SA account.

    The model database didn't have any additional users. Sids really weren't an isssue, otherwise SSMS would have blown up as well when adding the user.

    I'll post if I find out anything new.....

    Wednesday, February 17, 2010 5:57 PM
  • What I found was that the server had assigned the login xxx to the dbo account by default when I created the database.

    I changed the login property under the database's dbo user to a different user name and then I was able to map the database to the login that I wanted.

     

    Phil C.

     

     

    • Proposed as answer by onenj Friday, January 3, 2014 11:09 AM
    Thursday, October 21, 2010 6:52 PM
  • Hello Phil,

    How did you changed the login property under dbo-user of database? I see, than I have same username in my both databases, but the "Login name" field is deactivate.

    Thank you for answer.

    Best regards

    Valerij

    Friday, December 17, 2010 1:30 PM
  • I had a similar issue and resolved it following the instructions here: http://www.sqlservercentral.com/Forums/FindPost788976.aspx

    Basically you just run this command inside the database you are trying to fix:

    sp_changedbowner 'sa'
    GO
    That will clear out "dbo" as the owner of the database and allow you to set the login to a different user.
    Wednesday, August 7, 2013 5:08 PM
  • The reply from @philcr gave me the clue I needed. I had a different user (from the original database that I had restored) which was mapping the login. So I renamed it to the one I wanted in the new host. In fairness, that was what the error message was trying to tell me, but until I read this reply I hadn't understood what it was telling me.
    Wednesday, June 28, 2017 5:26 PM