Você pode criar procedimentos armazenados que fazem referência a objetos que ainda não existem (por exemplo, tabelas e funções). Você não pode criar procedimentos armazenados que fazem referência a colunas que ainda não existem em objetos que já existem. Essa é a faca de dois gumes da resolução de nomes adiados - o SQL Server oferece o benefício da dúvida em alguns casos, mas não em todos. Veja as idéias de Erland SET STRICT_CHECKS ON;
para obter algumas idéias dos locais em que isso funciona e dos locais em que está quebrado:
http://www.sommarskog.se/strict_checks.html
(E como ele gostaria do oposto do que você procura - você deseja permitir que qualquer coisa seja compilada, independentemente da existência, e ele deseja que todas as colunas ou tabelas sejam verificadas.)
Não existe uma configuração como SET DEFERRED_NAME_RESOLUTION OFF;
se tivesse sido solicitada:
http://connect.microsoft.com/sql/127152
E não há configuração como IGNORE ALL_RESOLUTION;
.
Você pode contornar isso de várias maneiras, incluindo:
(a) use SQL dinâmico nos procedimentos armazenados afetados.
(b) construa um stub para CREATE PROCEDURE
nada, depois execute o restante do seu script e execute um ALTER PROCEDURE
que tenha o corpo real (em essência, implante o procedimento em duas fases).
(c) torne sua ferramenta de implantação mais inteligente sobre a ordem das operações. Se as alterações na tabela exigirem a presença de uma função, faça o script dessas alterações por último. Ferramentas de comparação de esquema como o SQL Compare do RedGate são muito boas para gerar scripts para você na ordem de dependência adequada. Você não menciona qual ferramenta está usando, mas se não estiver fazendo isso ...
(d) Martin Smith tem uma solução interessante aqui , mas eu não brinquei com isso.