10

I just imported an existing SQL Server 2008r2 production database into a VS 2013 database project.

I now get a number of errors along the lines of

Error       SQL71501: User: [mydbuser] has an unresolved reference to Login [mydbuser].

I don't really need my VS DB project to manage users, but I'm concerned that it would try to remove them upon deploy if they weren't there.

The files themselves are generated as

CREATE USER [mydbuser] FOR LOGIN [mydbuser];

or

CREATE USER [mydomainuser] FOR LOGIN [MYDOMAIN\mydomainuser];

The error marker shows that it's specifically for the Login. As that's a system-level object, I can understand it being outside the scope of the db project.

Is it preferred that I change them all to

CREATE USER [mydbuser] WITHOUT LOGIN;

or add the CREATE LOGIN clause to the beginning of each file?

Removing the login reference seems to be simpler and removing the users altogether would be the simplest.

I want to make sure that I'm using the tool the way it was intended. Will there be any issues in re-publishing any of those back to production? What is the proper procedure for adding a user/login via a project?

  • 1
    I just noticed that it didn't happen for all users. They all happened to be SQL users, and some were disabled (though others were not). Any ideas where to start looking for differences? – Greg Jul 20 '15 at 20:34
7

The easiest way is to not manage users through ssdt (most people don't). So you can just strip them out and don't deploy logins or users.

There are three ways:

Ed

9

I had the same problem and found this link

User has an unresolved reference to Login

If you create application specific logins (which you should) then you are going to come across this error when trying to build your solution. To correct this error, select include 'Non-Application-scoped' object types in the options (gear icon at top) when you do a schema compare (right-click the database project to find Schema Compare). You can then just import the logins into your regular project, and the references are sorted. Note: If you click on the Object Types tab and it closes the dialog (which it did for me), instead use the tab key until Application-scoped is highlighted, then press the down arrow to highlight Non-Application-scoped and press the space bar. Now you should be able to click OK and see the logins.

  • 1
    Thank you for the response! Could you provide some context for these instructions? For example, what does schema compare have to do with this error? Where is the Object Types tab? Where do you hit the tab key? Etc. – Jake Oct 11 '16 at 3:22
  • Sure. Basically in VS2013/2015 you have your database project which contains all your SQL for the solution you are using. If you right click on that DB project and click on "Schema Compare" you can compare whats in your project with whats in your database. At the top of the window that pops up is a Cog icon for the settings. You cant click on "Non-Application-Scoped" checkbox with your mouse for some reason so use the tab key instead. Press the tab key once, then the arrow down key and then the space bar to select it. Hope that helps. – SpeedOfSpin Oct 12 '16 at 14:29
1

Apparently, this issue is still occurring on VS2017 database projects as well.

I've managed to solve it by first creating the login and then create the user.

    -- Windows Account
    CREATE LOGIN [Domain\Username]
    FROM WINDOWS WITH DEFAULT_LANGUAGE = [us_english];

    GO

    CREATE USER [Domain\Username] FOR LOGIN [Domain\Username];
    GO

    -- Sql Acccount

    CREATE LOGIN [sql_account] WITH PASSWORD = 'Ch@ngeth1spA$swurD'
    GO

    CREATE USER [sql_account]
    FROM LOGIN [sql_account]
    WITH DEFAULT_SCHEMA = dbo

    GO


    -- Then set the sql file Build Action to "Build"

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.