Ошибка при создании сборки в SQL: MSG 33009

Question

Я пытаюсь загрузить dll в MSSQL с помощью:

USE dbname
GO

CREATE ASSEMBLY foo 
FROM 'C:\foo\foo.dll'
WITH PERMISSION_SET = UNSAFE
GO

И я получаю сообщение об ошибке:

Msg 33009, Level 16, State 2, Line 2
The database owner SID recorded in the master database differs from the database owner 
SID recorded in database 'dbname'. You should correct this situation by resetting the 
owner of database 'dbname' using the ALTER AUTHORIZATION statement.

MSDN на самом деле не говорит мне больше об ошибке, чем сама ошибка.

Я просмотрел весь Интернет и пришел к выводу, что единственное, что кто-либо когда-либо делал, чтобы избежать этого, это:

use dbname
go
EXEC dbo.sp_changedbowner @loginame = N'sa', @map = false

Но действительно ли смена владельца - единственный способ избежать этой ошибки? Зачем мне это делать, есть ли другой способ? Я хотел бы получить дополнительную информацию об этой ошибке, прежде чем войти и слепо сменить владельца.

Answer 1

У меня была точно такая же проблема, и единственным решением для меня было сменить владельца, а затем снова поменять его.

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

Answer 2

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

удалить пользователя [MyUser]; exec sp_changedbowner [MyUser]

Чтобы решить эту проблему в долгосрочной перспективе, удалите пользователя из базы данных «модель» (Security / Logins / [MyUser] Properties - User Mapping).