Solution:
Check to view in case your user is mapped to the DB you are attempting to log into.
We had the similar error deploying a report to SSRS in our PROD environment. It was constructed the issue could even be reproduced with a “use ” statement. The resolution was to re-sync the user's GUID account reference with the database in question (for example employing "sp_change_users_login" like you would after restoring a db). A stock (cursor driven) script to re-sync all accounts is attached:
USE <your database>
GO
-------- Reset SQL user account guids ---------------------
DECLARE @UserName nvarchar(255)
DECLARE orphanuser_cur cursor for
SELECT UserName = su.name
FROM sysusers su
JOIN sys.server_principals sp ON sp.name = su.name
WHERE issqluser = 1 AND
(su.sid IS NOT NULL AND su.sid <> 0x0) AND
suser_sname(su.sid) is null
ORDER BY su.name
OPEN orphanuser_cur
FETCH NEXT FROM orphanuser_cur INTO @UserName
WHILE (@@fetch_status = 0)
BEGIN
--PRINT @UserName + ' user name being resynced'
exec sp_change_users_login 'Update_one', @UserName, @UserName
FETCH NEXT FROM orphanuser_cur INTO @UserName
END
CLOSE orphanuser_cur
DEALLOCATE orphanuser_cur
The fact that I had forgotten which specific database I was targeting my connection to. I was managing the standard SQL Server connection window to enter the credentials:
I had to check the Connection Properties tab to accomplish that I was selecting the right database to connect to. I had unexpectedly left the Connect to database option here fixed to a selection from a former session. This is why I was unable to connect to the database I thought I was attempting to connect to.
Note that you require to click the Options >>
button in order for the Connection Properties and other tabs to show up.
This performed for me:
use <Database>
EXEC sp_change_users_login @Action='update_one', @UserNamePattern='<userLogin>',@LoginName='<userLogin>';
The problem can be noticed with:
SELECT sid FROM sys.sysusers WHERE name = '<userLogin>'
SELECT sid FROM sys.syslogins WHERE name = '<userLogin>';
SQL Logins are defined at the server level, and should be mapped to Users in particular databases.
In SSMS object explorer, under the server you want to modify, expand Security > Logins, then double-click the appropriate user which will bring up the "Login Properties" dialog.
Choose user Mapping, which will display all databases on the server, with the ones having an subsisting mapping chosen. From here you can choose additional databases (and certain to choose which roles in each database that user must belong to), then click OK to include the mappings.
These mappings can become disconnected after a restore or same operation. In this instance, the user may still subsist in the database however is not really mapped to a login. In case that occurs, you can run the following to restore the login:
USE {database};
ALTER USER {user} WITH login = {login}
You can further delete the DB user and recreate it from the Login Properties dialog, however any role memberships or other settings would require to be recreated.
In my instance, the message was happened by a synonym which inadvertently added the database name in the "object name". At the time I restored the database under a new name, the synonym still pointed to the old DB name. Because the user did not have permissions in the old DB, the message appeared. To solve, I dropped and recreated the synonym without qualifying the object name with the database name:
USE [new_db]
GO
/****** Object: Synonym [dbo].[synTable] Script Date: 10/15/2015 9:45:01 AM ******/
DROP SYNONYM [dbo].[synTable]
GO
/****** Object: Synonym [dbo].[synTable] Script Date: 10/15/2015 9:45:01 AM ******/
CREATE SYNONYM [dbo].[synTable] FOR [dbo].[tTheRealTable]
GO