Разбирам въпроса ви като „когато правя промяна в схемата, искам да потвърдя всички процедури, които те все още изпълняват правилно с новата схема“. т.е. ако изпуснете колона, която е посочена в SELECT в процедура, тогава искате тя да бъде маркирана, тъй като изисква промени. Така че конкретно не разбирам въпроса ви като „Искам процедурата да се прекомпилира при следващо изпълнение“, тъй като тази задача се поема вместо вас от двигателя, който ще открие промяната на версията на метаданните, свързана с всяка промяна на схемата, и ще отхвърли съществуващата кеширани планове за изпълнение.
Първото ми наблюдение е, че това, което описвате във въпроса си, обикновено е работа на ТЕСТ и трябва да имате стъпка за проверка на качеството в процеса на внедряване, която валидира новата „компилация“. Най-доброто решение, което бихте могли да имате, е да приложите минимален набор от модулни тестове, които най-малкото преминават през всички ваши съхранени процедури и валидират изпълнението на всеки за коректност, в тестово внедряване. Това до голяма степен ще елиминира всички изненади, поне ще ги елиминира там, където боли (в производството или на сайта на клиента).
Вашият следващ най-добър вариант е да разчитате на вашите инструменти за разработка, за да проследите тези зависимости. Visual Studio Database 2008 Database Edition предоставя такава функционалност веднага и ще се погрижи за валидирането на всяка промяна, която направите в схемата.
И накрая последната ви опция е да направите нещо подобно на предложеното от KM:автоматизирайте итерация през всички ваши процедури в зависимост от модифицирания обект (и всички процедури в зависимост от зависимите и така нататък и така нататък рекурсивно). Няма да е достатъчно да маркирате процедурите за повторно компилиране, това, от което наистина се нуждаете, е да изпълните ALTER PROCEDURE, за да задействате анализ на неговия текст и валидиране на схемата (нещата са малко по-различни в T-SQL спрямо обичайния ви език цикъл на компилиране/изпълнение, „компилирането“ само по себе си се случва само когато процедурата действително се изпълни). Можете да започнете, като преминете през sys.sql_dependencies
за да намерите всички зависимости на вашия променен обект, както и да намерите „дефиницията на модула“ на зависимостите от 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
След това можете да преминете през зависимите „модули“ и да ги създадете отново (т.е. да ги пуснете и да изпълните кода в „дефиницията“). Обърнете внимание, че „модулът“ е по-генеричен от съхранена процедура и обхваща също изгледи, тригери, функции, правила, настройки по подразбиране и филтри за репликация. Шифрованите „модули“ няма да имат налична дефиниция и за да бъдете абсолютно правилни, трябва да отчетете и различните настройки, записани в sys.sql_modules (ansi нули, обвързване на схема, изпълнение като клаузи и т.н.).
Ако използвате ynamic SQL, това не може да бъде потвърдено. Няма да бъде уловен от sys.sql_dependencies , нито ще бъде валидиран чрез „пресъздаване“ на модула.
Като цяло смятам, че най-добрият ви вариант, до голяма степен, е да приложите валидирането на единичните тестове.
