Я видел это почти в каждой версии SQL Server, и сообщения в блогах об этом, похоже, воспринимают это как нечто, возникающее время от времени, но, поскольку мне всегда кажется, что я сталкиваюсь с этой проблемой, вплоть до SQL Server 2017, сейчас настало время найти что я делаю не так
Сценарий:
- База данных с пользователем SQL Server (не AD)
- Резервное копирование (т.е. в файл), а затем восстановить на другом компьютере или сервере базы данных
Теперь пользователь появится для этой базы данных, но не может быть использован и не может быть добавлен в логины (поскольку он будет жаловаться, что он уже существует):
- При удалении этого пользователя будет выброшено: участник базы данных владеет схемой в базе данных и не может быть удален.
Затем:
Невозможно удалить это право собственности:
- Предоставление прав собственности другому пользователю не облегчает эту проблему
Есть несколько решений (это один, или это один) , чтобы исправить это после того, как -фактум, но я хотел бы, чтобы исправить это в корне:
- Могу ли я сделать резервную копию базы данных без ее пользователей?
- Могу ли я восстановить базу данных без ее пользователей?
- Могу ли я сделать резервную копию / восстановить базу данных с ее пользователями (они являются пользователями SQL, поэтому они должны быть экспортируемыми)?
- Что-нибудь еще, т. Е. Могу ли я как-то создать логины для отчужденных пользователей, или что еще я делаю в корне неправильно?
Я выполняю большинство своих действий с помощью консоли управления SQL Server, что может быть нецелесообразно, но я с радостью изучаю лучшую технику, чем инструменты, которые должны делать это для нас.
Документация MS является ложной
Это должно быть легко, по мнению Microsoft:
Когда база данных восстанавливается на другом компьютере, логин SQL Server или пользователь Microsoft Windows, который инициирует операцию восстановления, автоматически становится владельцем новой базы данных. Когда база данных восстановлена, системный администратор или новый владелец базы данных может изменить владельца базы данных.
Все это, по-видимому, в корне неверно, как показано в приведенном выше сценарии.
Отказ от ответственности: я искал, но не удивлюсь, если это дубликат.
PS: в основном, разочарование, как правило, вы восстанавливаете в экстренных случаях. Тратить часы на "исправление" того, что не должно быть сломано, очень раздражает. Не невозможно, не неразрешимо, просто неприятность.
PPS: выполнение SELECT name FROM sys.schemas WHERE principal_id = USER_ID('TeamcityUsr') для приведенного выше примера возвращает пустой набор. Таким образом, пользователь, который был скопирован, действительно отчужден.