Analizar todos los procedimientos almacenados en una base de datos

¿Alguien sabe de una forma de verificar la exactitud de las consultas en todos los procedimientos almacenados en una base de datos? Estoy pensando en el escenario donde si modificas algo en un archivo de código, simplemente haciendo una reconstrucción mostraría errores de compilación que te dirigen a lugares donde necesitas arreglar cosas. En un escenario de base de datos, por ejemplo, si modifica una tabla y elimina una columna que se utiliza en un procedimiento almacenado, no sabrá nada sobre este problema hasta la primera vez que se ejecute dicho procedimiento.Analizar todos los procedimientos almacenados en una base de datos

Fuente

2010-09-18 CyberDude

posible duplicado de (http [¿Cómo puedo comprobar mediante programación (análisis sintáctico) la validez de una declaración TSQL?]: // stackoverflow. com/questions/3084387/how-can-i-programmatically-check-parse-the-validity-of-a-tsql-statement) @CyberDude - Puede usar 'SET NOEXEC ON' pero creo que la mejor manera es escribir una utilidad para realmente tratar de ejecutarlos y deshacerlos. –

Supongo que podría crear una secuencia de comandos dinámica que enumera todos los procedimientos y trata de ejecutarlos. Una parte interesante sería simular todos los parámetros necesarios ... Otra forma sería recuperar el texto del procedimiento e intentar hacer un 'ALTER PROCEDURE' pero sin cambiar nada dentro. – CyberDude

El análisis es un primer paso útil, y podría analizar procedimientos almacenados revisados para validar su sintaxis. Pero cargarlos en el DB hará eso, así que esto no es una gran ganancia. Verificar que funcionen por algún método regular parece mucho más útil. La respuesta de "pruebas unitarias" proporcionada por OMG Ponies es bastante buena. –

Lo que usted describe es para qué sirve la prueba unitaria. Los procedimientos y funciones almacenados a menudo requieren el establecimiento de parámetros, y si el procedimiento o función almacenada encapsula SQL dinámico, existe la posibilidad de que se pierda un caso de [esquina].

Además, todo lo que menciona es comprobar si hay errores básicos, nada sobre la validación de los datos devueltos. Por ejemplo, puedo cambiar la precisión en una columna numérica ...

Esto también entra en las pruebas básicas que deben ocurrir para el problema inmediato, y las pruebas de regresión para garantizar que no haya problemas imprevistos.

Fuente

2010-09-18 18:21:11

Puede crear todos sus objetos con SCHEMABINDING, lo que le impediría cambiar las tablas subyacentes sin descartar y volver a crear las vistas y los procedimientos creados sobre ellos.

Dependiendo de su proceso de desarrollo, esto podría ser bastante engorroso. Sin embargo, lo ofrezco como una solución, porque si quieres garantizar la exactitud de todos los procedimientos en la base de datos, esto lo haría.

Fuente

2010-09-18 18:36:28

Encontré este ejemplo en MSDN (SQL Server 2012). Creo que se puede utilizar en algunos escenarios:

USE AdventureWorks2012; 
GO 

SELECT p.name, r.* 
FROM sys.procedures AS p 
CROSS APPLY sys.dm_exec_describe_first_result_set_for_object(p.object_id, 0) AS r;

Fuente: sys.dm_exec_describe_first_result_set_for_object

Fuente

2013-05-13 11:49:36

Analizar todos los procedimientos almacenados en una base de datos

Respuesta

Cuestiones relacionadas