2013-09-25 101 views
59

Tôi đang cố gắng truy cập cơ sở dữ liệu máy chủ lưu trữ của mình thông qua SQL Server Management Studio, mọi thứ cho đến khi đăng nhập vẫn ổn. Nhưng khi tôi sử dụng lệnh use myDatabase nó cung cấp cho tôi lỗi này:Máy chủ chính không thể truy cập cơ sở dữ liệu trong ngữ cảnh bảo mật hiện tại trong SQL Server MS 2012

The server principal "****" is not able to access the database "****" under the current security context. 

Tôi đã tìm kiếm qua và nhà cung cấp dịch vụ lưu trữ đã liệt kê this khắc phục sự cố.

Nhưng đây không phải đang làm việc cho tôi có lẽ vì nó cho SQL Server Management Studio 2008 tuy nhiên tôi đang sử dụng SQL Server Management Studio 2012.

này có thể là một vấn đề? Và nếu có hơn bất cứ ai có thể cho tôi biết nó thay thế trong SSMS 2012?

+2

'Nhà cung cấp dịch vụ lưu trữ'? Chúng ta đang nói chuyện riêng hay chia sẻ? Nếu đó là một máy chủ lưu trữ được chia sẻ, tôi khuyên bạn nên liên hệ với nhà cung cấp dịch vụ lưu trữ của bạn để được trợ giúp. SQL trong môi trường lưu trữ được chia sẻ nổi tiếng là lỗi và có vấn đề. Nó không liên quan gì đến sản phẩm nhưng các chính sách mà nhà cung cấp dịch vụ lưu trữ áp dụng cho (các) máy chủ. Mỗi công ty lưu trữ có cách riêng của họ để tận dụng SQL hoặc có vẻ như vậy. –

Trả lời

52

Kiểm tra xem liệu người dùng của bạn có được ánh xạ tới DB bạn đang cố gắng đăng nhập hay không.

+27

làm thế nào để bạn làm điều đó? – Graham

+2

@Graham Hoặc sử dụng SQL Server Management Studio để kiểm tra Người dùng hoặc xem câu trả lời này: http://stackoverflow.com/a/9356725/804773 – Grambot

+3

Tôi khuyên bạn nên tìm kiếm trình kích hoạt, đó là lý do tôi nhận được thông báo này, là trình kích hoạt đang thực hiện một số nội dung trong cơ sở dữ liệu khác mà người dùng của tôi không được ủy quyền. – DanielV

12

Chúng tôi đã gặp lỗi tương tự khi triển khai báo cáo cho SSRS trong môi trường PROD của chúng tôi. Nó đã được tìm thấy vấn đề thậm chí có thể được sao chép với một tuyên bố "sử dụng". Giải pháp là để đồng bộ hóa tham chiếu tài khoản GUID của người dùng với cơ sở dữ liệu được đề cập (tức là, bằng cách sử dụng "sp_change_users_login" như bạn sẽ làm sau khi khôi phục lại một db). Một cổ phiếu (con trỏ điều khiển) kịch bản để tái đồng bộ hóa tất cả các tài khoản được kèm theo:

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 
+1

Làm việc cho tôi Cảm ơn bạn. Tôi đã sao chép một cơ sở dữ liệu với xác thực máy chủ SQL đến máy chủ thử nghiệm của tôi và nó không thể truy cập được. Bây giờ nó là – MikeH

+0

Nếu người dùng tồn tại trong cơ sở dữ liệu nhưng không tồn tại một bản đồ để đăng nhập, xóa người dùng nói thông qua SSMS Object Explorer sau đó remapping Đăng nhập làm việc cho tôi. Nếu không, tôi nghi ngờ giải pháp được đề xuất ở trên sẽ cần phải được thực hiện. – jjt

3

Trong trường hợp của tôi, thông điệp được gây ra bởi một từ đồng nghĩa mà vô tình bao gồm tên cơ sở dữ liệu trong "tên đối tượng". Khi tôi khôi phục cơ sở dữ liệu dưới một tên mới, từ đồng nghĩa vẫn chỉ vào tên DB cũ. Vì người dùng không có quyền trong DB cũ, thông báo xuất hiện. Để khắc phục, tôi đã bỏ và tạo lại từ đồng nghĩa mà không đủ điều kiện tên đối tượng với tên cơ sở dữ liệu:

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 
0

Tôi gặp lỗi tương tự khi sử dụng Đối tượng quản lý máy chủ (SMO) trong vb.net (Tôi chắc chắn đó là giống nhau trong C#)

Nhận xét của Techie Joe về bài đăng đầu tiên là một cảnh báo hữu ích trong việc chia sẻ lưu trữ nhiều điều bổ sung đang diễn ra. Phải mất một ít thời gian để tìm ra, nhưng đoạn mã dưới đây cho thấy cách người ta phải rất cụ thể trong cách họ truy cập cơ sở dữ liệu SQL. Lỗi 'máy chủ chính ...' dường như xuất hiện bất cứ khi nào các cuộc gọi SMO không chính xác cụ thể trong môi trường lưu trữ được chia sẻ.

Đoạn mã đầu tiên này chống lại máy chủ SQL Express cục bộ và dựa vào Xác thực Windows đơn giản. Tất cả các mã được sử dụng trong các mẫu được dựa trên các hướng dẫn SMO bởi Robert Kanasz trong Code Project website article này:

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 

Đoạn mã trên phát hiện các tập tin MDF cho mỗi cơ sở dữ liệu trên máy chủ SQLEXPRESS địa phương tốt vì xác thực được xử lý bởi Windows và nó là rộng trên tất cả các cơ sở dữ liệu.

Trong mã sau có 2 phần lặp cho tệp .mdf. Trong trường hợp này chỉ có lần lặp đầu tiên tìm kiếm một filegroup hoạt động, và nó chỉ tìm thấy một tệp duy nhất vì kết nối là chỉ một cơ sở dữ liệu duy nhất trong môi trường lưu trữ được chia sẻ.

Lặp lại thứ hai, là bản sao của phép lặp đã làm việc ở trên, chokes ngay lập tức vì cách nó được ghi nó cố truy cập cơ sở dữ liệu thứ nhất trong môi trường chia sẻ, không phải là ID người dùng/Mật khẩu được áp dụng, vì vậy máy chủ SQL trả về lỗi ủy quyền dưới dạng lỗi 'máy chủ chính ...'.

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 

Trong vòng lặp thứ hai đó, mã biên dịch tốt, nhưng vì SMO không được thiết lập để truy cập chính xác cơ sở dữ liệu chính xác với cú pháp chính xác, cố gắng không thành công.

Vì tôi vừa mới học SMO, tôi nghĩ những người mới khác có thể cảm kích vì biết rằng cũng có một lời giải thích đơn giản hơn về lỗi này - chúng tôi đã viết mã sai.