Вы можете создавать хранимые процедуры, которые ссылаются на объекты, которые еще не существуют (например, таблицы и функции). Вы не можете создавать хранимые процедуры, которые ссылаются на столбцы, которые еще не существуют в объектах, которые уже существуют. Это обоюдоострый меч отложенного разрешения имен - SQL Server дает вам преимущество сомнения в некоторых случаях, но не во всех. Посмотрите на идеи Эрланда, SET STRICT_CHECKS ON;
чтобы получить некоторые представления о местах, где это работает, и местах, которые он разрушает:
http://www.sommarskog.se/strict_checks.html
(И как бы он хотел, чтобы полярная противоположность того, что вам нужно - вы хотите разрешить что-либо компилировать независимо от существования, и он хочет, чтобы каждый столбец или таблица проверялись.)
Там нет настройки, как SET DEFERRED_NAME_RESOLUTION OFF;
будто это было запрошено:
http://connect.microsoft.com/sql/127152
И нет такой настройки, как IGNORE ALL_RESOLUTION;
.
Вы можете обойти это несколькими способами, в том числе:
(a) использовать динамический SQL в затронутых хранимых процедурах.
(b) создайте заглушку, в CREATE PROCEDURE
которой ничего не будет, затем запустите остальную часть вашего сценария, затем запустите объект, ALTER PROCEDURE
имеющий реальное тело (по сути, разверните процедуру в два этапа).
(c) сделать ваш инструмент развертывания более умным в отношении порядка операций. Если для изменения таблицы требуется наличие функции, запишите эти изменения в последнюю очередь. Инструменты сравнения схем, такие как RedGate SQL Compare, довольно хороши для генерации скриптов для вас в правильном порядке зависимостей. Вы не упоминаете, какой инструмент используете, но если он этого не делает ...
(d) У Мартина Смита есть интересный обходной путь , но я не играл с ним.