o
the new server. When I went into Mgmt Studio I realized that the old
security settings associated with those db's carried over to the new server
when attached. However, they were no good because the user "abc" did not
exist as a valid login on this new server. I tried to delete it but it won'
t
allow it because there is no "login" associated with the user. Of course
there is none. it's a bogus record. For that same reason the Login screen
is grayed out and Mgmt Studio won't let me change it. I see absolutely no
way to remove it now (short of removing the security settings while it's
still in SQL 2000 before moving to 2005). Any suggestions on a way to
cleanup the security info and get it all redefined after moving to 2005?
Thanks
--Perhaps one of these will offer you a clue:
http://www.sqlservercentral.com/col...se
s.asp
Moving Users
http://www.support.microsoft.com/?id=246133 How To Transfer Logins and
Passwords Between SQL Servers
http://www.support.microsoft.com/?id=298897 Mapping Logins & SIDs after a
Restore
http://www.dbmaint.com/SyncSqlLogins.asp Utility to map logins to users
http://www.support.microsoft.com/?id=168001 User Logon and/or Permission
Errors After Restoring Dump
http://support.microsoft.com/kb/274188 Troubleshooting Orphan Logins
http://www.support.microsoft.com/?id=240872 Resolve Permission
Issues -Database Is Moved Between SQL Servers
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
You can't help someone get up a hill without getting a little closer to the
top yourself.
- H. Norman Schwarzkopf
"Spicie Mikie" <Maz@.newsgroups.nospam> wrote in message
news:7B7F056C-5EB2-4548-BB47-4D58F024860B@.microsoft.com...
> Here's a catch-22 with the new SQL 2005. I've attached some SQL 2000 db's
> to
> the new server. When I went into Mgmt Studio I realized that the old
> security settings associated with those db's carried over to the new
> server
> when attached. However, they were no good because the user "abc" did not
> exist as a valid login on this new server. I tried to delete it but it
> won't
> allow it because there is no "login" associated with the user. Of course
> there is none. it's a bogus record. For that same reason the Login
> screen
> is grayed out and Mgmt Studio won't let me change it. I see absolutely no
> way to remove it now (short of removing the security settings while it's
> still in SQL 2000 before moving to 2005). Any suggestions on a way to
> cleanup the security info and get it all redefined after moving to 2005?
> Thanks
> --
>|||That article about orphaned logins was exactly what I needed to read. I'm
still somewhat surprised that the UI gets "caught" by this situation and
cannot be fixed without using a stored procedure. However, this works, so
I'm happy
Thanks
--
Maz
"Arnie Rowland" wrote:
> Perhaps one of these will offer you a clue:
> http://www.sqlservercentral.com/col...
ses.asp
> Moving Users
> http://www.support.microsoft.com/?id=246133 How To Transfer Logins and
> Passwords Between SQL Servers
> http://www.support.microsoft.com/?id=298897 Mapping Logins & SIDs after a
> Restore
> http://www.dbmaint.com/SyncSqlLogins.asp Utility to map logins to users
> http://www.support.microsoft.com/?id=168001 User Logon and/or Permission
> Errors After Restoring Dump
> http://support.microsoft.com/kb/274188 Troubleshooting Orphan Logins
> http://www.support.microsoft.com/?id=240872 Resolve Permission
> Issues -Database Is Moved Between SQL Servers
>
> --
> Arnie Rowland, Ph.D.
> Westwood Consulting, Inc
> Most good judgment comes from experience.
> Most experience comes from bad judgment.
> - Anonymous
> You can't help someone get up a hill without getting a little closer to th
e
> top yourself.
> - H. Norman Schwarzkopf
>
> "Spicie Mikie" <Maz@.newsgroups.nospam> wrote in message
> news:7B7F056C-5EB2-4548-BB47-4D58F024860B@.microsoft.com...
>
>sql
