Для меня проблема звучит так, как будто установщик использует другой пользовательский контекст, чем ожидалось. Но это может быть трудно отследить, потому что эта ошибка не регистрируется по умолчанию, и сама ошибка на самом деле очень общая.
Если вдаваться в некоторые детали, это похоже на ошибку разрешения. Тем не менее, ошибкой является 262, что является общим «отказано в доступе к базе данных». Как видно из этого запроса:
SELECT * FROM sys.messages WHERE language_id = 1033 AND message_id = 262
У которого значение is_event_logged установлено в 0, а в виде текстового значения:
% ls в базе данных "%. * Ls" отказано в разрешении.
Мы можем включить ведение журнала для этого события (чтобы его можно было просматривать в журналах SQL Server), однако тогда оно будет регистрировать ВСЕ недостающие события разрешений, что в зависимости от того, насколько занят сервер, может быть много и можетбыть нежелательным.
Однако, чтобы дополнительно выяснить, в каком контексте установщик выполняет свои операции, мы можем включить его с помощью:
EXEC sp_altermessage @message_id = 262, @parameter = 'WITH_LOG' ,@parameter_value = 'true'
Когда установщик работает и выдается ошибкасобытие должно быть в журнале SQL Server (пример ниже делается просто с непривилегированным пользователем в TSQL):
Теперь, зная значение SPID, мыможно узнать пользовательский контекст, используя команду sp_who2. Который показывает связанный логин.
EXEC sp_who2
Этот логин должен быть от sysadmin / dbcreator или просто иметь разрешение CREATE DATABASE Server.
Я бы настоятельно рекомендовал запустить:
EXEC sp_altermessage @message_id = 262, @parameter = 'WITH_LOG' ,@parameter_value = 'false'
Когда все сделано, чтобы вернуть запись об этой ошибке в журналы SQL Server. Надеюсь, это поможет сузить проблему.