Как исправить. MS SQL Server: User, group, or role '*' already exists in the current database. (Microsoft SQL Server, Error: 15023).

2 комментария
Предыстория: Как-то ко мне обратились со следующим вопросом: Программа использующая в качестве СУБД MS SQL Server не видит одну из баз, причем в Management Studio база видна и данные в ней есть.

Попытка просто расставить необходимые права к ожидаемому результату не привела - при попытке установить права возникла ошибка:

Create failed for User '*'. (Microsoft.SqlServer.Smo)
User, group, or role '*' already exists in the current database. (Microsoft SQL Server, Error: 15023)





Копание в интернет привело к следующим рекомендациям:

Чтобы исправить данную ошибку, есть два различных способа в зависимости от версии SQL Server, который вы используете. Обе эти команды производят ремап (пере-ассоциацию) пользовательского идентификатора безопасности (SID), чтобы привести его в соответствие с SID в логине SQL Server'а.

Для SQL Server 2008 / SQL Server 2008 R2 / SQL Server 2012

ALTER USER user WITH LOGIN = serverlogin 

где имя проблемного serverlogin пользователя, а имя user пользователя в самой базе (подробнее по ссылке https://msdn.microsoft.com/ru-ru/library/ms176060.aspx)

Для более старых SQL Server 2005 / SQL Server 2000

EXEC sp_change_users_login 'Auto_Fix', 'user'

вся магия использования по прежнему по ссылке https://msdn.microsoft.com/ru-ru/library/ms174378.aspx

Но, как это и бывает в основной массе случаев, данный рецепт мне не помог.

Решение оказалось достаточно банальным:


Итак, по шагам:

  1. Открываем интересующую нас базу в Microsoft SQL Server Management Studio
  2. Идем в раздел Security -> Users. Там открываем интересующего нас пользователя
  3. Открываем вкладку General
  4. В разделе Database role membership выбираем необходимые нам права (мне хватило бы db_datawriter и db_datareader)

На этом все! База подключается, данные пишутся-читаются.

Разбор полетов: Было очень важно узнать как же данный инцидент мог произойти дабы исключить его в дальнейшем. Расследование показало достаточно обидный промах - база была восстановлена из резервной копии пользователем sa, что в конечном итоге привело к смене db_owner, а права на чтение и запись у нашего пострадавшего пользователя не были установлены (до переноса базы он успешно работал с ней как владелец).

Выводы (не претендующие на объективность):

  1. Всегда необходимо проверять не только возможность авторизации пользователя, но и наборы его прав на интересующую нас базу.
  2. Восстановление (перенос на новый сервер) лучше осуществлять под тем пользователем, который будет с данной базой работать в дальнейшем.
  3. В случае ошибки подключения пользователя с базе или сообщения, что базы не существует - можно выдать данному пользователю права System Administrator для проверки возможности подключения и уверования в неправильно выставленные права. Работать из-вне с правами System Administrator крайне не желательно.

2 комментария :

  1. Спасибо! очень помогло. После переезда на новый сервер с тем же именем, распались права и пользователи =) Поудалять из Security каждой базы помогло.

    ОтветитьУдалить