Hi psiegers,

I often update my dev site, from my live site, including it's DB, to keep a copy in Dev as close as possible to the live version.  When I do a db restore, I do a full restore using the sql db from the live site.  I know this isn't perhaps the normal way of doing it, but I don't know how to keep the two sites synchronized, so I was forced to find a solution for continuously needing to fix the db logins.  This is what I found.

The db logins are not necessarily the same, even though they may be named the same in your connection strings in the web.config file.  For example, if your login is "mysite" and your db is "mysite_db" one one host, and you move to another host, even with the exact same connection strings, it may not work and allow you a login. So, this sql statement "fixes" that issue automatically.  This is executed in the db in the query window.  So if you can connect to your db, with any sql software that will allow you to run a query, it should work.  SQLExpress works for me when I do this.

<code>

EXEC sp_change_users_login 'Auto_Fix', 'yourdbname', NULL, 'yourlogin'
GO

</code>

So, if you know the db name, the login name, and the strings are correct in web.config, connect to your db via an sql manager of some kind, run this query and you should be fine.

Clay

Hi Duncan, thanx for the information - I'll have a closer look into orphaned users to determine if my problem is related with that.

Updated: I found out that I had one orphaned user; I had this login created on my local DB to be able to use it on a new host, but since that host didn't work out, we created a new package on the same host and it turned out that both DBs now live on the same SQL box, with different names but both had the same sql login defined. So I removed the login where I don't need it (my develop DB) and dropped and recreated the same login in the new client DB, and that problem is now solved. Once again thanx Duncan - I can now move on to port the dev site to the new one.