sp_send_dbmail được thực hiện từ công việc không thành công với kết quả truy vấn được đính kèm dưới dạng tệp

Question

Tôi gặp phải sự cố sau: khi cố gắng gửi email với kết quả truy vấn được đính kèm dưới dạng tệp, sử dụng sp_send_dbmail thông qua thực hiện truy vấn thông thường mọi thứ dường như hoạt động OK.

Nhưng nếu thêm cùng một mã vào JobStep và chạy công việc thì không thành công.

Lỗi trong lịch sử công việc nói

truy vấn Lỗi định dạng, thông số có lẽ không hợp lệ [SQLSTATE 42000] (Lỗi 22050). Bước không thành công.

Nhưng khi tôi nhận xét tham số tham chiếu đến tệp đính kèm, nó bắt đầu hoạt động bình thường trở lại.

exec msdb.dbo.sp_send_dbmail 
    @profile_name = 'profile_name', 
    @recipients = 'some@mail.com', 
    @body = 'body', 
    @subject = 'subj', 
    --Parameters that refers to attached file 
    @attach_query_result_as_file = 1, 
    @query_result_header = 0, 
    @query_result_no_padding = 1, 
    @query = 'select 1', 
    @query_attachment_filename = 'test.csv' 

Mọi đề xuất?

Answer 1

Tôi đã giải quyết vấn đề đó. Không biết tại sao nó sẽ làm việc nhưng không bao giờ ít hơn. :) Đó chắc chắn là về bảo mật.

Tôi đã điều tra rằng Tác nhân SQL đang hoạt động thay mặt cho người dùng miền, giả sử DOMAIN \ User. Nó có đầy đủ các quyền quản trị trên máy chủ (vai trò máy chủ 'sysadmin', v.v.). Bản thân SQL Server đang chạy dưới cùng một người dùng đó.

Bước công việc có cuộc gọi đến sp_send_dbmail chạy dưới cùng một DOMAIN \ User.

Ngoài ra tôi đã bắt nguồn từ đó khi chạy phần truy vấn của sp_send_dbmail nó cố gắng để thực hiện exec xp_logininfo 'DOMAIN \ User' để kiểm tra đối với Active Directory nếu người dùng đó là OK. Và ngạc nhiên: một điều chắc chắn không ổn. việc kiểm tra này kết thúc với:

Msg 15404, Level 16, State 19, Server SQLC002INS02\SQLC002INS02, Line 1 
Could not obtain information about Windows NT group/user 'DOMAIN\User.', error code 0x2. 

đó, với một số khả năng có thể có nghĩa là bất cứ điều gì về mật khẩu của người dùng đó là hết hạn sử dụng hoặc bị khóa hoặc bất kỳ điều thú vị không khác cho anh chàng đó.

Tôi đã quyết định rằng sẽ nguy hiểm khi thay đổi người dùng cho Đại lý. Vì vậy, tôi đến để gửi thư thay mặt cho 'sa' trong đó có vai trò máy chủ 'sysadmin' cùng nhưng ủy quyền SQL và bỏ qua bước kiểm tra AD này.

Nó trông giống như một người dùng mà giả vờ là quản trị viên để yêu cầu người quản trị thực để chạy mã nguy hiểm cho anh ta :)

đang Vậy cuối cùng của công việc này là người đầu tiên và bước chỉ giống như thế này:

execute as login = 'sa' 
exec msdb.dbo.sp_send_dbmail 
    @profile_name = 'profile_name', 
    @recipients = 'some@mail.com', 
    @body = 'body', 
    @subject = 'subj', 
    --Parameters that refers to attached file 
    @attach_query_result_as_file = 1, 
    @query_result_header = 0, 
    @query_result_no_padding = 1, 
    @query = 'select 1', 
    @query_attachment_filename = 'test.csv' 
revert 

Answer 2

Khi bạn thực hiện truy vấn của mình theo cách thủ công, thông tin đăng nhập CỦA BẠN được sử dụng. Khi tác nhân SQL thực hiện cùng một truy vấn, thông tin đăng nhập của tài khoản dịch vụ đại lý SQL được sử dụng. Theo mặc định, SQL Server Agent sẽ sử dụng thông tin đăng nhập tài khoản LocalSystem. Một cách để khắc phục sự cố là thay đổi người dùng mà dịch vụ Đại lý máy chủ SQL đang chạy với người dùng có quyền truy cập vào thư mục csv \ của bạn.

Answer 3

Tôi gặp sự cố này.Tôi đang sử dụng SQL Server 2008 R2. Tôi đã nhận được email gửi đi với biết thêm về lỗi bằng cách thêm tùy chọn:

@append_query_error = 1, 

tôi đã nhận được email với lỗi này về quyền thay vì truy vấn của tôi:

Msg 916, Level 14, State 1, Server SERVER\INST01, 
Procedure GetSalesReport, Line 62 
The server principal "CONTROLLEDNETWO\sql.service" is not able 
to access the database "MYDB01" under the current security co 
ntext. 

truy vấn của tôi đã cố gắng để truy cập vào một số bảng nơi mà SQL Agent không có quyền (thực ra trong trường hợp của tôi nó thậm chí không truy cập vào nó).

Tôi đã sửa nó qua SQLSMS bằng cách thêm người dùng mới "CONTROLLEDNETWO \ sql.service" vào db "MYDB01" và cấp quyền "chọn".

Answer 4

Tôi tin rằng vấn đề này là do thay đổi được thực hiện trong SQL 2008 và sau đó liên quan đến việc khóa bảo mật chỉ với sp_send_dbmail. Nó chỉ xảy ra nếu bạn vượt qua một qry để send_dbmail để thực hiện, và trả lại kết quả thông qua email. Vấn đề là thông báo lỗi là gây hiểu lầm và không phù hợp. Một giải pháp tốt là tạo một người dùng SQL chỉ với các quyền cần thiết tối thiểu để thực hiện truy vấn đó. Ví dụ: db_reader hoặc db_writer và db_owner nếu cần thiết. Và biến người dùng đó thành chủ sở hữu. Bạn cũng có thể tạo thông tin xác thực SQL và định cấu hình công việc sql đó để chạy theo thông tin đăng nhập SQL đó.

Answer 5

Tôi cũng gặp sự cố này và đã giải quyết nó trong hai phần bằng cách sử dụng nhiều lời khuyên ở đây.

1) Nhấp chuột phải, 'Xem lịch sử' trên công việc hiển thị chi tiết lỗi và thông báo lỗi đã cho biết tên người dùng đang chạy, vì vậy tôi đã cấp cho người dùng quyền truy cập chỉ đọc này vào DB của tôi.

2) Tôi đã quên chỉ định DBName.dbo .MyTableName và chỉ đang sử dụng MyTableName.

Ngẫu nhiên, tất cả email đều chuyển đến thư mục email rác của tôi.

Answer 6

EXEC msdb.dbo.sp_send_dbmail 
    @profile_name = 'Main Profile', 
    @recipients = 'me@vwp.com', 
    @subject = 'Test', 
    @body = 'this is a test', 
    @execute_query_database = 'myTargetDatabase_mscrm', 
    @query = N'SELECT * from myTargetDatabase_mscrm.dbo.SystemUserBase', 
    @attach_query_result_as_file = 1, 
    @query_attachment_filename = 'Test.txt' 

Để tham chiếu, việc này không được hiển thị nhiều lần như được gọi là quản trị viên tên miền, nhưng chạy dưới dạng địa phương \ sqladmin. Sau khi lật các biến vào một ngày và cố gắng cấp quyền, tôi thấy trong kịch bản lệnh của công việc mà nó vẫn đang sử dụng cơ sở dữ liệu chủ. Tôi thấy thiết lập nhìn chằm chằm vào mặt tôi. Đó là cấu hình cho Bước. Tôi đã thay đổi nó thành msdb và nó hoạt động. Hãy nhớ rằng tôi đã thay đổi lựa chọn từ myTable để chọn từ myDatabase.dbo.myTable dựa trên một số bài viết. Điều đó có thể hoặc có thể không góp phần khắc phục sự cố. Tôi cũng đã sử dụng @execute_query_database để đảm bảo rằng nó đang chạy truy vấn từ đúng nơi. Một lần nữa, điều đó có thể không cần thiết.

Không có vấn đề gì cuối cùng đã làm cho nó hạnh phúc, nó không có gì để làm với cho dù đó là gắn hay không.

Answer 7

Điều này rất hữu ích cảm ơn bạn. Muốn chia sẻ những gì tôi đã cố gắng để làm với excel (xls) tập tin đính kèm đã được đặt kết quả trong cột. Điều này làm việc cho tôi bằng cách thêm query_result_no_padding = 1 và query_result_separator = ','. (đó là một Tab, Tab trong các dấu tích)

@query_result_header= 1, 
@attach_query_result_as_file = 1, 
@query_result_no_padding = 1, 
@query_attachment_filename = 'TestPriceFlingerReport.xls', 
@query_result_separator= ' , ', 
@profile_name = 'Test Exchange Server' 

Answer 8

trong trường hợp của tôi, Nó không thể xác định bảng thuộc về cơ sở dữ liệu. Khi database.dbo.table được thêm vào truy vấn nó đã làm việc.