Je comprends votre question comme suit :"lorsque je modifie un schéma, je souhaite valider toutes les procédures qu'ils exécutent toujours correctement avec le nouveau schéma". C'est à dire. si vous supprimez une colonne référencée dans un SELECT dans une procédure, vous souhaitez qu'elle soit signalée car elle nécessite des modifications. Donc, spécifiquement, je ne comprends pas votre question comme "Je veux que la procédure se recompile à la prochaine exécution", puisque ce travail est pris en charge pour vous par le moteur, qui détectera le changement de version des métadonnées associé à toute modification de schéma et supprimera l'existant plans d'exécution mis en cache.
Ma première observation est que ce que vous décrivez dans votre question est généralement le travail d'un TEST et vous devriez avoir une étape d'assurance qualité dans votre processus de déploiement qui valide la nouvelle "construction". La meilleure solution que vous pourriez avoir est d'implémenter un ensemble minimal de tests unitaires qui, à tout le moins, parcourent toutes vos procédures stockées et valident l'exécution de chacun pour l'exactitude, dans un déploiement de test. Cela éliminerait à peu près toutes les surprises, du moins les éliminerait là où ça fait mal (en production ou sur le site du client).
Votre deuxième meilleure option consiste à vous fier à vos outils de développement pour suivre ces dépendances. Le Visual Studio Database 2008 Database Edition fournit une telle fonctionnalité prête à l'emploi et il se chargera de valider toute modification que vous apportez au schéma.
Et enfin votre dernière option est de faire quelque chose de similaire à ce que KM a suggéré :automatiser une itération à travers toutes vos procédures en fonction de l'objet modifié (et toutes les procédures en fonction de celles qui en dépendent et ainsi de suite de manière récursive). Il ne suffira pas de marquer les procédures pour la recompilation, ce dont vous avez vraiment besoin est d'exécuter la PROCÉDURE ALTER pour déclencher une analyse de son texte et une validation du schéma (les choses sont un peu différentes en T-SQL par rapport à votre langage habituel cycle compile/execute, la 'compilation' proprement dite ne se produit que lorsque la procédure est réellement exécutée). Vous pouvez commencer par parcourir le sys.sql_dependencies
pour trouver toutes les dépendances de votre objet modifié, et également trouver la 'définition de module' des dépendances 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
Vous pouvez ensuite parcourir les "modules" dépendants et les recréer (c'est-à-dire les supprimer et exécuter le code dans la "définition"). Notez qu'un 'module' est plus générique qu'une procédure stockée et couvre également les vues, les déclencheurs, les fonctions, les règles, les valeurs par défaut et les filtres de réplication. Les 'modules' chiffrés n'auront pas de définition disponible et pour être absolument correct, vous devez également prendre en compte les différents paramètres capturés dans sys.sql_modules (nulls ansi, liaison de schéma, exécution en tant que clauses, etc.).
Si vous utilisez du SQL dynamique, cela ne peut pas être vérifié. Il ne sera pas capturé par sys.sql_dependencies , ni il ne sera validé en 'recréant' le module.
Dans l'ensemble, je pense que votre meilleure option, de loin, est de mettre en œuvre la validation des tests unitaires.
