Движущаяся база данных к новому серверу
Не уверенный, почему эта проблема происходит, хотя это только для определенных клиентов, таким образом, это могло зависеть от того, как веб-хост обрабатывает записи "A".
В любом случае я добавил следующую строку к vHost файлу для одного из моих клиентов:
ServerAlias subdomain.clientsite.tld *.subdomain.clientsite.tld
и это, казалось, добивалось цели. Получил идею из этой ссылки: http://www-01.ibm.com/software/webservers/httpservers/doc/v1326/manual/vhosts/name-based.html
In SQL-Server 2008 the database users for a restored database and server logins may be out of sync because the internals IDs do not match. To fix this run:
EXEC sp_change_users_login @Action=''Update_One'', @UserNamePattern='databaseusername', @LoginName = 'logonname';
against your restored database and for each user/login.
In SQL-Server 2012 there is a new option to use database users independent of server logins.
I know that I'm late on this, but it might help someone else.
Logins are at the server level. Users are at the database level. There is an ID value (called a SID) that joins the two together. When you create a SQL login on a new server, SQL pick a new SID value. The nature of the SID-picking algorithm is that you won't get the same value on two different servers. When you restore the database from the old server, the SID value from the database doesn't match the SID value on the server.
At that point, you want to use sp_change_users_login.
But, BEFORE you get to that point, you can save yourself a lot of aggravation, particularly if you have a log of logins to migrate from an old server to a new server. Look at sp_help_revlogin. This is a proc that is supported by Microsoft. The proc and documentation is located here and here. (There are different versions of the procedure for different versions of SQL Server. There is also a helper function called 'sp_hexadecimal'.) Basically, you need to create those procedures on your old server and then run them. The KB articles have details.
The big win of sp_help_revlogin is that it produces user creation DDL that preserves the ID value and the password for SQL logins. This way, you can just run sp_help_revlogin, look through the generated DDL to find the users you need, run that code on the new server and then just restore the database. At that point, the SID values should match up and you won't need sp_change_users_login.
The other way around this is to use integrated (aka "domain" or "windows") security. When using AD logins, the SID value is pulled from the domain when you create the login. That SID value is then placed in the database when you create the database user for that login. Since there is only one source for SID values, no mismatch can occur. Of course, using integrated security is not always possible.