Vaši otázku chápu jako „když provedu změnu schématu, chci ověřit všechny procedury, které stále provádějí správně s novým schématem“. Tj. pokud vypustíte sloupec, na který se odkazuje v SELECT v proceduře, chcete jej označit příznakem, protože vyžaduje změny. Takže konkrétně nerozumím vaší otázce jako „Chci, aby se postup znovu zkompiloval při příštím spuštění“, protože o tuto úlohu se za vás postará engine, který zjistí změnu verze metadat související s jakoukoli změnou schématu a zahodí existující realizační plány uložené v mezipaměti.
Můj první postřeh je, že to, co popisujete ve své otázce, je obvykle úkolem TESTU a v procesu nasazení byste měli mít krok kontroly kvality, který ověří nové „sestavení“. Nejlepším řešením, které byste mohli mít, je implementovat minimální sadu testů jednotek, které přinejmenším projdou všemi vašimi uloženými procedurami a ověří spuštění každého za správnost v testovacím nasazení. To by v podstatě eliminovalo všechna překvapení, alespoň je eliminovala tam, kde to bolí (ve výrobě nebo u zákazníka).
Vaší další nejlepší možností je spolehnout se na vaše vývojové nástroje při sledování těchto závislostí. Visual Studio Database 2008 Database Edition poskytuje takové funkce ihned po vybalení a postará se o ověření jakékoli změny, kterou ve schématu provedete.
A konečně vaší poslední možností je udělat něco podobného, co navrhl KM:automatizovat iteraci všech vašich procedur v závislosti na upraveném objektu (a všech procedur závislých na závislých a tak dále a tak dále rekurzivně). Nestačí označit procedury pro rekompilaci, to, co opravdu potřebujete, je spustit ALTER PROCEDURE pro spuštění analýzy jejího textu a ověření schématu (v T-SQL je to trochu jiné než ve vašem obvyklém jazyce kompilace/provedení, 'kompilace' sama o sobě nastane pouze tehdy, když je procedura skutečně provedena). Můžete začít iterací přes sys.sql_dependencies
najít všechny závislosti vašeho změněného objektu a také najít „definici modulu“ závislostí z 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
Poté můžete projít závislé 'moduly' a znovu je vytvořit (tj. zahodit je a spustit kód v 'definici'). Všimněte si, že „modul“ je obecnější než uložená procedura a zahrnuje také pohledy, spouštěče, funkce, pravidla, výchozí hodnoty a filtry replikace. Šifrované 'moduly' nebudou mít definici k dispozici a aby byly naprosto správné, musíte také počítat s různými nastaveními zachycenými v sys.sql_modules (hodnoty ansi null, vazba schématu, provedení jako klauzule atd.).
Pokud používáte dynamické SQL, nelze to ověřit. Nebude zachycen sys.sql_dependencies , ani nebude ověřen 'znovu vytvořením' modulu.
Celkově se domnívám, že vaší nejlepší možností je s velkou rezervou implementovat validaci testů jednotek.