Entiendo su pregunta como 'cuando realizo un cambio de esquema, quiero validar todos los procedimientos que aún se ejecutan correctamente con el nuevo esquema'. Es decir. si suelta una columna a la que se hace referencia en un SELECCIONAR en un procedimiento, quiere que se marque como que requiere cambios. Entonces, específicamente, no entiendo su pregunta como 'Quiero que el procedimiento se vuelva a compilar en la próxima ejecución', ya que el motor se encarga de ese trabajo, que detectará el cambio de versión de metadatos asociado con cualquier alteración del esquema y descartará el existente planes de ejecución en caché.
Mi primera observación es que lo que describe en su pregunta suele ser el trabajo de un PRUEBA y debe tener un paso de control de calidad en su proceso de implementación que valide la nueva 'construcción'. La mejor solución que podría tener es implementar un conjunto mínimo de pruebas unitarias que, como mínimo, repita todos sus procedimientos almacenados y valide la ejecución de cada uno para la corrección, en una implementación de prueba. Eso eliminaría prácticamente todas las sorpresas, al menos eliminarlas donde duele (en producción o en el sitio del cliente).
Su siguiente mejor opción es confiar en sus herramientas de desarrollo para rastrear estas dependencias. El Base de datos de Visual Studio 2008 Edición de base de datos proporciona dicha funcionalidad lista para usar y se encargará de validar cualquier cambio que realice en el esquema.
Y finalmente, su última opción es hacer algo similar a lo que sugirió KM:automatice una iteración a través de todos sus procedimientos dependiendo del objeto modificado (y todos los procedimientos dependiendo de los dependientes y así sucesivamente recursivamente). No será suficiente marcar los procedimientos para la recompilación, lo que realmente necesita es ejecutar ALTER PROCEDURE para desencadenar un análisis de su texto y una validación del esquema (las cosas son un poco diferentes en T-SQL frente a su lenguaje habitual ciclo de compilación/ejecución, la 'compilación' en sí ocurre solo cuando el procedimiento se ejecuta realmente). Puede comenzar iterando a través del sys.sql_dependencies
para encontrar todas las dependencias de su objeto alterado y también encontrar la 'definición de módulo' de las dependencias de sys.sql_modules
:
with cte_dep as (
select object_id
from sys.sql_dependencies
where referenced_major_id = object_id('<your altered object name>')
union all
select d.object_id
from sys.sql_dependencies d
join cte_dep r on d.referenced_major_id = r.object_id
)
, cte_distinct as (
select distinct object_id
from cte_dep)
select object_name(c.object_id)
, c.object_id
, m.definition
from cte_distinct c
join sys.sql_modules m on c.object_id = m.object_id
Luego puede ejecutar los 'módulos' dependientes y volver a crearlos (es decir, soltarlos y ejecutar el código en la 'definición'). Tenga en cuenta que un 'módulo' es más genérico que un procedimiento almacenado y cubre también vistas, disparadores, funciones, reglas, valores predeterminados y filtros de replicación. Los 'módulos' cifrados no tendrán una definición disponible y, para ser absolutamente correctos, también debe tener en cuenta las diversas configuraciones capturadas en sys.sql_modules (ansi nulos, enlace de esquema, ejecución como cláusulas, etc.).
Si usa SQL dinámico, eso no se puede verificar. No será capturado por sys.sql_dependencies , ni será validado 're-creando' el módulo.
En general, creo que su mejor opción, por un amplio margen, es implementar la validación de pruebas unitarias.
