2009-04-28 3 views
7

У меня есть следующие настройки:Проблема с SQL Server «EXECUTE AS»

Там является SQL Server DB с несколькими таблицами, которые имеют триггеры, установленные на них (которые собирают данные истории). Эти триггеры являются хранимыми процедурами CLR с EXECUTE AS 'HistoryUser'. Пользователь HistoryUser - простой пользователь в базе данных без входа в систему. Он имеет достаточно разрешений для чтения из всех таблиц и записи в таблицу истории.

Когда я делаю резервное копирование БД и затем восстанавливаю его на другой компьютер (в этом случае виртуальная машина, но это не имеет значения), триггеры больше не работают. Фактически, никакое олицетворение для пользователя больше не работает. Даже простое утверждение, например, как это

exec ('select 3') as user='HistoryUser' 

выдает ошибку:

Cannot execute as the database principal because the principal "HistoryUser" does not exist, this type of principal cannot be impersonated, or you do not have permission.

Я read in MSDN, что это может произойти, если владелец БД пользователь домена, но это не так. И даже если я изменю его на что-нибудь еще (их рекомендуемое решение), эта проблема остается.

Если я создаю другого пользователя без входа в систему, я могу использовать его для олицетворения просто отлично. То есть, это работает просто отлично:

create user TestUser without login 
go 
exec ('select 3') as user='TestUser' 

Я не хочу, чтобы воссоздать все эти триггеры, так есть ли способ, как я могу сделать существующую HistoryUser работу?

Bump: Извините, но это своего рода срочно ...

ответ

4

Что пользователь учетная запись триггером выполняться как.

Вам необходимо предоставить привилегии пользователя IMPERSONATE для пользователя HistoryUser учетной записи пользователя.

GRANT IMPERSONATE ON USER:: YourUser TO HistoryUser 

Подробнее здесь

http://msdn.microsoft.com/en-us/library/ms181362.aspx

+0

Nop, не помогает. –

4

Проблема, как это, возникающая после перемещения базы данных с одного компьютера на другой, как правило, включает несовпадающий SID, хотя я не уверен, или, как он относится к ваш случай. Попробуйте удалить и повторно создать пользователя базы данных, убедившись, что восстановите его разрешения для этих таблиц.

+0

Это просто точка - у этого пользователя никогда не было логина. Какие SID? И, как я уже сказал в вопросе выше, я бы предпочел не воссоздать пользователя, потому что тогда мне также нужно воссоздать целую кучу триггеров. –

+0

Это сработало для меня. Нам пришлось перенести базу данных с другого сервера и столкнулись с этой проблемой. – ahwm

3

Это «осиротевший пользователь». Это не сработает. Документация гласит, что это ясно. :-( :-( Исправить положение «осиротевший пользователь», и он снова будет работать

+2

Какая документация - не могли бы вы предоставить ссылку? благодаря – doza

5

Обнаруживать осиротевших пользователей, а затем разрешить, связавшись с логином.

ОБНАРУЖЕНИЕ:

USE <database_name>;
GO;
sp_change_users_login @ Действие = ' Отчет ';
GO;

постановляю:
Следующая команда перелинкует сервера регистрации учетной записи, указанной < регистрационного_имени > с пользователем базы данных, указанной <database_user>:

USE <database_name>;
GO
sp_change_users_login @ Action = ' update_one ',
@ UserNamePattern = ' <database_user> ',
@ LoginName = ' <login_name> ';
GO

https://msdn.microsoft.com/en-us/library/ms175475.aspx

Смежные вопросы