Принцип сервера не может получить доступ к базе данных в текущем контексте безопасности в SQL Server MS 2012

Ответ 1

Проверьте, отображается ли ваш пользователь в базе данных, к которой вы пытаетесь войти.

Ответ 2

У нас была такая же ошибка при развертывании отчета для SSRS в нашей среде PROD. Было обнаружено, что проблема может быть даже воспроизведена с помощью "использования". Решение заключалось в том, чтобы повторно синхронизировать ссылку учетной записи пользователя GUID с соответствующей базой данных (например, используя "sp_change_users_login", как если бы вы восстановили db). Добавлен запас (курсор) script для повторной синхронизации всех учетных записей:

USE <your database>
GO

-------- Reset SQL user account guids ---------------------
DECLARE @UserName nvarchar(255) 
DECLARE orphanuser_cur cursor for 
      SELECT UserName = su.name 
      FROM sysusers su
      JOIN sys.server_principals sp ON sp.name = su.name
      WHERE issqluser = 1 AND
            (su.sid IS NOT NULL AND su.sid <> 0x0) AND
            suser_sname(su.sid) is null 
      ORDER BY su.name 

OPEN orphanuser_cur 
FETCH NEXT FROM orphanuser_cur INTO @UserName 

WHILE (@@fetch_status = 0)
BEGIN 
--PRINT @UserName + ' user name being resynced' 
exec sp_change_users_login 'Update_one', @UserName, @UserName 
FETCH NEXT FROM orphanuser_cur INTO @UserName 
END 

CLOSE orphanuser_cur 
DEALLOCATE orphanuser_cur

Ответ 3

Я потратил довольно много времени на борьбу с этой проблемой, а потом понял, что совершаю простую ошибку в том, что забыл, к какой именно базе данных я подключался. Я использовал стандартное окно подключения к SQL Server для ввода учетных данных:

Мне пришлось проверить вкладку " Свойства подключения ", чтобы убедиться, что я выбираю правильную базу данных для подключения. Я случайно оставил здесь параметр "Подключиться к базе данных" для выбора из предыдущего сеанса. Вот почему я не смог подключиться к базе данных, к которой, как мне казалось, я пытался подключиться.

Обратите внимание, что вам нужно нажать кнопку " Options >>, чтобы отобразились свойства подключения и другие вкладки.

Ответ 4

В моем случае сообщение было вызвано синонимом, который непреднамеренно включал имя базы данных в "имя объекта". Когда я восстановил базу данных под новым именем, синоним все еще указывал на старое имя БД. Поскольку у пользователя не было разрешений в старой БД, появилось сообщение. Чтобы исправить это, я сбросил и воссоздал синоним без определения имени объекта с именем базы данных:

    USE [new_db]
GO

/****** Object:  Synonym [dbo].[synTable]    Script Date: 10/15/2015 9:45:01 AM ******/
DROP SYNONYM [dbo].[synTable]
GO

/****** Object:  Synonym [dbo].[synTable]    Script Date: 10/15/2015 9:45:01 AM ******/
CREATE SYNONYM [dbo].[synTable] FOR [dbo].[tTheRealTable]
GO

Ответ 5

Это сработало для меня:

use <Database>
EXEC  sp_change_users_login @Action='update_one', @UserNamePattern='<userLogin>',@LoginName='<userLogin>';

Проблема может быть визуализирована с помощью:

SELECT sid FROM sys.sysusers WHERE name = '<userLogin>'
SELECT sid FROM sys.syslogins WHERE name = '<userLogin>';

Ответ 6

Я столкнулся с той же ошибкой при использовании объектов управления сервером (SMO) в vb.net(я уверен, что это то же самое на С#)

Techie Joe комментирует первоначальный пост, было полезным предупреждением о том, что в совместном хостинге происходит много дополнительных вещей. Понадобилось немного времени, чтобы выяснить, но приведенный ниже код показывает, как нужно быть очень конкретным в том, как они обращаются к базам данных SQL. Ошибка "server princip...", казалось, появлялась всякий раз, когда вызовы SMO не были точно конкретными в среде совместного размещения.

Этот первый раздел кода был против локального сервера SQL Express и опирался на простую аутентификацию Windows. Весь код, используемый в этих образцах, основан на учебнике SMO Роберта Канаша в этой статье веб-сайта Code Project:

  Dim conn2 = New ServerConnection()
  conn2.ServerInstance = "<local pc name>\SQLEXPRESS"
  Try
    Dim testConnection As New Server(conn2)
    Debug.WriteLine("Server: " + testConnection.Name)
    Debug.WriteLine("Edition: " + testConnection.Information.Edition)
    Debug.WriteLine(" ")

    For Each db2 As Database In testConnection.Databases
      Debug.Write(db2.Name & " - ")
      For Each fg As FileGroup In db2.FileGroups
        Debug.Write(fg.Name & " - ")
        For Each df As DataFile In fg.Files
          Debug.WriteLine(df.Name + " - " + df.FileName)
        Next
      Next
    Next
    conn2.Disconnect()

  Catch err As Exception
    Debug.WriteLine(err.Message)
  End Try

Вышеприведенный код обнаруживает, что файлы .mdf для каждой базы данных на локальном сервере SQLEXPRESS просто прекрасны, поскольку проверка подлинности обрабатывается Windows, и она широко распространена во всех базах данных.

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

Вторая итерация, которая является копией итерации, которая работала выше, немедленно сжимается, потому что, как она написана, она пытается получить доступ к первой базе данных в общей среде, которая не является той, к которой ИД пользователя/Пароль применяется, поэтому SQL-сервер возвращает ошибку авторизации в форме ошибки "главный сервер...".

Dim sqlConnection1 As New System.Data.SqlClient.SqlConnection
sqlConnection1.ConnectionString = "connection string with User ID/Password to a specific database in a shared hosting system. This string will likely also include the Data Source and Initial Catalog parameters"
Dim conn1 As New ServerConnection(sqlConnection1)
Try
  Dim testConnection As New Server(conn1)
  Debug.WriteLine("Server: " + testConnection.Name)
  Debug.WriteLine("Edition: " + testConnection.Information.Edition)
  Debug.WriteLine(" ")

  Dim db2 = testConnection.Databases("the name of the database to which the User ID/Password in the connection string applies")
  For Each fg As FileGroup In db2.FileGroups
    Debug.Write(fg.Name & " - ")
    For Each df As DataFile In fg.Files
      Debug.WriteLine(df.Name + " - " + df.FileName)
    Next
  Next

  For Each db3 As Database In testConnection.Databases
    Debug.Write(db3.Name & " - ")
    For Each fg As FileGroup In db3.FileGroups
      Debug.Write(fg.Name & " - ")
      For Each df As DataFile In fg.Files
        Debug.WriteLine(df.Name + " - " + df.FileName)
      Next
    Next
  Next

  conn1.Disconnect()

Catch err As Exception
  Debug.WriteLine(err.Message)
End Try

В этом втором цикле итераций код компилируется отлично, но поскольку SMO не настроен на то, чтобы получить доступ к точно такой же базе данных с точным синтаксисом, эта попытка не выполняется.

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

Ответ 7

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

После попытки удалить пользователя было обнаружено, что несколько SP содержали "with execute as" этого пользователя.

Проблема была решена путем удаления этих SP, удаления пользователя, воссоздания пользователя, связанного с логином, и воссоздания SP.

Возможно, он попал в это состояние после восстановления из резервной копии (во время, когда соответствующий логин не существовал) или массовой синхронизации схемы (если возможно создать SP с выполнением, даже если пользователь не существует. Может также иметь были связаны с этим ответом.

Ответ 8

Логины SQL определяются на уровне сервера и должны быть сопоставлены с пользователями в определенных базах данных.

В обозревателе объектов SSMS на сервере, который вы хотите изменить, разверните Безопасность > Логины, затем дважды щелкните по соответствующему пользователю, который вызовет диалоговое окно "Свойства входа в систему".

Выберите User Mapping, который покажет все базы данных на сервере, с выбранными существующими. Отсюда вы можете выбрать дополнительные базы данных (и обязательно укажите, к каким ролям в каждой базе данных должен принадлежать этот пользователь), затем нажмите кнопку ОК, чтобы добавить сопоставления.

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

USE {database};
ALTER USER {user} WITH login = {login}

Вы также можете удалить пользователя БД и воссоздать его в диалоговом окне "Свойства входа в систему", но необходимо повторно создать членство в любой роли или другие параметры.