sql server - query - El archivo sp_send_dbmail ejecutado desde el trabajo falla con el resultado de la consulta adjunto como archivo

sp_send_dbmail ejemplos

Question

Me he enfrentado con el siguiente problema: al intentar enviar un correo electrónico con los resultados de la consulta adjunta como archivo, utilizando sp_send_dbmail mediante la ejecución de una consulta normal, todo parece funcionar bien.

Pero si agrega el mismo código en JobStep y ejecuta el trabajo, falla.

El error en el historial de trabajo dice

Error al formatear la consulta, probablemente parámetros no válidos [SQLSTATE 42000] (Error 22050). El paso falló.

Pero cuando comento un parámetro que hace referencia al archivo adjunto, comienza a funcionar correctamente de nuevo.

exec msdb.dbo.sp_send_dbmail
@profile_name = ''profile_name'',
@recipients = ''[email protected]'',
@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''

¿Alguna sugerencia?

Answer 1

Creo que este problema se debió a un cambio implementado en SQL 2008 y más tarde en relación con el bloqueo de seguridad solo para sp_send_dbmail. Solo sucede si pasas una qry a send_dbmail para ejecutar, y devuelves los resultados a través del correo electrónico. El problema es que el mensaje de error es engañoso y no es apropiado. Una buena solución es crear un usuario de SQL con los permisos mínimos necesarios para realizar esa consulta. Por ejemplo, db_reader, o db_writer, y db_owner si es absolutamente necesario. Y haz de ese usuario el propietario. También puede crear una credencial de SQL y configurar ese trabajo de SQL para que se ejecute bajo esa credencial de SQL.

Answer 2

Cuando ejecuta manualmente su consulta, se utilizan SUS credenciales. Cuando el Agente SQL ejecuta la misma consulta, se usan las credenciales de la cuenta de servicio del Agente SQL. De forma predeterminada, el Agente SQL Server utilizará las credenciales de la cuenta LocalSystem. Una forma de solucionar el problema sería cambiar el usuario bajo el cual se ejecuta el servicio del Agente SQL Server con un usuario que tiene acceso a su archivo / directorio csv.

Answer 3

En mi situación, no se pudo identificar la tabla a la que pertenece la base de datos. Una vez que se agregó database.dbo.table a la consulta, funcionó.

Answer 4

He venido a la solución de ese problema. No sé por qué funcionaría, pero nunca menos. :) Definitivamente se trata de seguridad.

He investigado que el Agente SQL se está ejecutando en nombre del usuario del dominio, digamos DOMAIN / User . Tiene un conjunto completo de derechos de administrador en el servidor (función de servidor ''sysadmin'', etc.). SQL Server se está ejecutando bajo ese mismo usuario.

El paso del trabajo que contiene la llamada a sp_send_dbmail se ejecuta bajo el mismo DOMINIO / Usuario .

También he rastreado que, al ejecutar la parte de consulta de sp_send_dbmail , intenta ejecutar exec xp_logininfo ''DOMINIO / Usuario'' para verificar con Active Directory si ese usuario está bien. Y sorpresa: algo definitivamente no está bien. Este cheque termina con:

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.

Eso, con cierta probabilidad, puede significar que la contraseña de ese usuario está vencida o el usuario está bloqueado o cualquier otra cosa que no sea agradable para ese tipo.

Decidí que es arriesgado cambiar de usuario para el agente. Entonces llego a enviar correo en nombre de ''sa'' que tiene el mismo rol de servidor ''sysadmin'' pero la autorización de SQL y omite este paso de comprobación de AD.

Parece que un usuario que pretende ser administrador le pide al administrador real que ejecute un código peligroso para él :)

Así que el código final de este trabajo es el primero y el único paso se parece a esto:

execute as login = ''sa''
exec msdb.dbo.sp_send_dbmail
@profile_name = ''profile_name'',
@recipients = ''[email protected]'',
@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 5

Todo esto fue útil gracias. Quería compartir lo que estaba tratando de hacer con el adjunto de excel (xls) que puso los resultados en columnas. Esto me funcionó al agregar el query_result_no_padding = 1, y query_result_separator = '',''. (eso es una pestaña, pestaña en las garrapatas)

@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 6

Tuve este problema Estoy usando SQL Server 2008 R2. Recibí el correo electrónico enviado con más información sobre el error agregando la opción:

@append_query_error = 1,

Recibí el correo electrónico con este error sobre los permisos en lugar de mi consulta:

 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.

Mi consulta intentaba acceder a algunas tablas donde el Agente SQL no tenía permisos (en mi caso, ni siquiera tiene acceso a él).

Lo arreglé a través de SQLSMS agregando un nuevo usuario "CONTROLLEDNETWO / sql.service" a la base de datos "MYDB01" y otorgando permisos para "seleccionar".

Answer 7

Yo también tuve este problema, y ​​lo resolví en dos partes usando gran parte de los consejos que se encuentran aquí.

1) Haga clic con el botón derecho en ''Ver historial'' en el trabajo que muestra los detalles de la falla, y el aviso de falla le dio el nombre del usuario en el que se ejecutó el trabajo, por lo que le di a este usuario acceso de solo lectura a mi base de datos.

2) Me había olvidado de especificar DBName.dbo .MyTableName y estaba usando MyTableName solamente.

Por cierto, todos los correos electrónicos iban a mi carpeta de correo no deseado.

Answer 8

EXEC msdb.dbo.sp_send_dbmail
@profile_name = ''Main Profile'',
@recipients = ''[email protected]'',
@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''

Para referencia, esto falló repetidamente mostrando como invocado como administrador del dominio, pero se ejecuta como local / sqladmin. Después de apagar las variables y tratar de dar permisos, vi en la secuencia de comandos del trabajo que todavía estaba usando la base de datos maestra. Encontré el escenario mirándome fijamente a la cara. Está en la configuración para el Paso. Lo cambié a msdb y funcionó. Tenga en cuenta que cambié la selección de myTable para seleccionar desde myDatabase.dbo.myTable en función de algunas publicaciones. Eso puede o no haber contribuido a solucionar el problema. También usé @execute_query_database para asegurarme de que está ejecutando la consulta desde el lugar correcto. De nuevo, eso podría no haber sido necesario.

No importaba lo que finalmente lo hiciera feliz, no tenía nada que ver con si se adjuntaba o no.