I have actually ran into the same problem (and had the same solution as Del) several times. The problem (at least on my end) is that I was backing up the database on server A and restoring it to Server B, which has an identical security model. Sporadically, the login at the database level will still be associated with Server A. The only solution I have found that works is to drop the login at the DB level, then add the DB to the server-level login. This is using SQL Server 2000.

-Justin

>I'm not sure why you would have to drop the user. The purpose of sp_change_user_login is to map an orphaned database user to an existing login.
>
>-Mike
>
>
>>>> Thru looking at the code and trial and error, I was able to get the following to seem to work by executing the following from the query analyzer (message said 1 orphaned user was fixed):
>>>
>>>sp_change_users_login 'UPDATE_ONE', 'closing', 'closing'
>>>>
>>
>>Okay, what I figured out is I had to execute sp_dropuser 'closing' next. Then I could actually remove the login in SEM. At that point I could create a new 'closing' login (via SEM) and give access to the database. Seems pretty convoluted. Is this what you would have done, Mike?
>>
>>I have Que's Using SQL Server 7.0, but it doesn't go into much detail on these kinds of things either. Do you have a book recommendation that gives me a little more detail on things like this? One thing that would be nice is a reference on all the sp's, what the parameters are, and when one would need to use them. Any thoughts along these lines?
>>
>>Del