Прежде всего, я восстановил базу данных с другого сервера, и теперь все хранимые процедуры названы как [azamsharp]. [Usp_getlatestposts]. Я думаю, что [azamsharp] имеет префикс, поскольку это был пользователь на исходном сервере.
Теперь на моей локальной машине это не работает. Мне не нужен префикс [azamsharp] для всех хранимых процедур.
Кроме того, когда я щелкаю правой кнопкой мыши на Sproc, я даже не вижу параметр свойств. Я использую SQL SERVER 2005 в Windows 7.
ОБНОВИТЬ:
Странно то, что если я обращаюсь к производственной базе данных со своего компьютера, я вижу параметр свойств. Итак, с безопасностью Windows 7 действительно что-то не так.
ОБНОВЛЕНИЕ 2:
Когда я запустил хранимую процедуру для пользователей-сирот, она показала двух пользователей «azamsharp» и «dbo1». Я исправил пользователя «azamsharp», но «dbo1» не исправляется. Когда я запускаю следующий скрипт:
exec sp_change_users_login 'update_one', 'dbo1', 'dbo1' Я получаю следующую ошибку:
Msg 15291, уровень 16, состояние 1, процедура sp_change_users_login, строка 131 Завершение этой процедуры. Имя для входа 'dbo1' отсутствует или недействительно.
У вас наверняка есть осиротевшие пользователи. Когда вы получаете доступ к серверу со своего компьютера, ваши учетные данные домена, вероятно, имеют доступ как DBadmin к производственному серверу. Запустите этот код, чтобы обнаружить пользователей-сирот:
Use TestDB
sp_change_users_login 'report'
В выходных данных перечислены все имена входа, которые имеют несоответствие между записями в системной таблице sysusers, в базе данных TestDB и в системной таблице sysxlogins в базе данных master. решить проблему:
Устранение потерянных пользователей
Use TestDB
sp_change_users_login 'update_one', 'test', 'test'
SELECT sid FROM dbo.sysusers WHERE name = 'test'
0x40FF09E48FBD3354B7833706FD2C61E4
use master
SELECT sid FROM dbo.sysxlogins WHERE name = 'test'
0x40FF09E48FBD3354B7833706FD2C61E4
Это повторно связывает вход на сервер "test" с пользователем базы данных TestDB "test". Хранимая процедура sp_change_users_login также может выполнять обновление всех потерянных пользователей с параметром «auto_fix», но это не рекомендуется, поскольку SQL Server пытается сопоставить имена входа и пользователей. В большинстве случаев это работает; однако, если с пользователем связан неправильный логин, у пользователя могут быть неправильные разрешения.