SQL Server Account Issue - sql-server

Question

I am currently using SQL Server 2005 and I try to restore a database from couple of months ago but when I restore it when I try to create a account it tells me that the account already exists but you cannot see it under security. I tried dropping that account but it tells me that the account does not exist to drop...But when I try to create it, it tells me that it exists... It is driving me insane. I completely removed that account from the server and all the linked servers and all the databases and I tried to re-create it again it works on all database except one that it keeps on saying it already exists. Any ideas what it could be or what else I should be checking?

Answer 1

You are having orphaned user accounts in database. It is very common issue when you copy/move your database from one server to another server. You will need to remove them from database user Or more better option is to create Server Login and map that login with that orphaned database user.
While back I wrote about it in my blog with some demo script, you may want to look at it. Or just look at this MSDN link for use of SP which can be used to manager orphaned users.

Answer 2

As a DBA, I get this problem all the time. And the GUI is not much of a help. Your SQL server has the accounts you want, the db has the accounts you want, but they don't auto-connect on restore.
The REAL way to fix this is to STOP-USING-INDIVIDUAL-ACCOUNTS. Only provide access to DBs on the basis of being a member of an active directory group. Then you can give access issues to the AD-group. BTW: While individual accounts don't auto-reconnect on a restore, group-access does.
Here is some code I use to address the same issue.
create procedure [dbo].[proc_FarSyncLogins] #TargetDB nvarchar(128)= '' as
begin
SET NOCOUNT ON
declare #cmd varchar(1000)
begin try
drop table master.dbo.NeededUsers
end try
begin catch
print 'could not: drop table master.dbo.NeededUsers'
end catch
set #cmd='select name collate Latin1_General_CI_AS as name,is_disabled
into master.dbo.NeededUsers
from ['+#TargetDB+'].sys.sql_logins'
--print #cmd
exec(#cmd)
print 'logins that need to be enabled'
select * from master.dbo.NeededUsers
declare #UserName nvarchar(128)
declare SyncUsers1 cursor fast_forward for SELECT Name FROM master.dbo.NeededUsers
OPEN SyncUsers1
FETCH NEXT FROM SyncUsers1 INTO #UserName
WHILE ##FETCH_STATUS = 0
BEGIN
set #cmd = ''
if #TargetDB <> ''
begin
set #cmd=#cmd+'Use ['+#TargetDB+']; '+char(10)
end
begin try
SET #cmd = #cmd+'ALTER LOGIN ['+#UserName+'] ENABLE; '+char(10)
SET #cmd = #cmd+'exec sp_change_users_login #Action=''Auto_Fix'', #UserNamePattern ='''+#UserName+'''; '+char(10)
PRINT #cmd
EXEC(#cmd)
end try
begin catch
Print 'Failed :'+#cmd
end catch
FETCH NEXT FROM SyncUsers1 INTO #UserName
END
CLOSE SyncUsers1
DEALLOCATE SyncUsers1
end
Then just
exec master.dbo.proc_FarSyncLogins '<yourDBName>';
It IS determinately HACKY, you will want to read the output carefully to verify you meant to do all those actions. But most of the time you just want to restore everything that you had before.

Answer 3

The account exists in the database and at the server level.
So you need to drop the account from the database itself but not from the server as it deosn't exist there.
have you tried...
use {yourdatabasename}
go
EXEC sp_dropuser '{username}'