Wyłączanie sprawdzania schematu przy tworzeniu funkcji / procedury składowanej

Próbuję zautomatyzować proces, który wykonuje zmiany w bazie danych SQL Server 2008 R2. Proces, który wprowadzam, upuszcza i odtwarza moje procedury składowane i funkcje, a także uruchamia skrypty w celu zmiany tabel / kolumn / danych. Niestety, jeden ze skryptów wymaga, aby jedna z funkcji była wprowadzona jako pierwsza. Ale nie mogę najpierw uruchomić wszystkich zapisanych zmian proc / funkcji, ponieważ polega to na dodaniu kolumn ze skryptów zmiany tabel / kolumn / danych.

Zastanawiałem się, czy można uruchomić procedury składowane i funkcje bez SQL Server sprawdzania poprawności kolumn używanych w definicji funkcji / SP? Próbowałem szukać, ale nie mogłem znaleźć warunku lub polecenia, aby to umożliwić.

Możesz tworzyć procedury składowane, które odwołują się do obiektów, które jeszcze nie istnieją (np. Tabele i funkcje). Nie można tworzyć procedur składowanych, które odwołują się do kolumn, które jeszcze nie istnieją w obiektach, które już istnieją. Jest to obosieczny miecz o odroczonym rozpoznawaniu nazw - SQL Server daje w niektórych przypadkach wątpliwości, ale nie wszystkie. Zobacz pomysły Erlanda, SET STRICT_CHECKS ON;aby uzyskać pomysły na miejsca, w których to działa i na miejsca, w których się psuje:

http://www.sommarskog.se/strict_checks.html

(A jak chciałby, by było to przeciwieństwo biegunowe tego, czego szukasz - chcesz pozwolić na kompilację czegokolwiek bez względu na istnienie, a on chce sprawdzić każdą kolumnę lub tabelę.)

Nie ma takiego ustawienia, jak SET DEFERRED_NAME_RESOLUTION OFF;gdyby zostało o to poproszone:

http://connect.microsoft.com/sql/127152

I nie ma takiego ustawienia IGNORE ALL_RESOLUTION;.

Można to obejść na kilka sposobów, w tym:

(a) używać dynamicznego SQL w odpowiednich procedurach przechowywanych.

(b) zbuduj kod pośredniczący, w CREATE PROCEDUREktórym nic nie ma, a następnie uruchom resztę skryptu, a następnie uruchom program, ALTER PROCEDUREktóry ma prawdziwe ciało (w istocie, uruchom procedurę w dwóch fazach).

(c) spraw, aby Twoje narzędzie wdrażania było mądrzejsze w kwestii kolejności operacji. Jeśli zmiany w tabeli wymagają obecności funkcji, należy je skrypty wykonać jako ostatnie. Narzędzia do porównywania schematów, takie jak porównywanie SQL RedGate, są dość dobre w generowaniu skryptów w odpowiedniej kolejności zależności. Nie wspominasz o tym, jakiego narzędzia używasz, ale jeśli to nie robi ...

(d) Martin Smith ma tutaj ciekawe obejście , ale nie bawiłem się nim.

Możesz utworzyć procedurę składowaną, która najpierw usuwa lub zmienia nazwę danego obiektu, a następnie uruchamia oryginalną procedurę składowaną jako dynamiczny SQL. W ten sposób nie trzeba przepisywać rzeczywistej procedury składowanej, aby użyć dynamicznego SQL.

Poniższy kod uruchamia procedurę składowaną, która odwołuje się do kolumn, które jeszcze nie istnieją (Expense_Super_Compare)

IF OBJECT_ID('Expense_Super_Compare_Results', 'U') IS NOT NULL
BEGIN
     EXEC('DROP TABLE Expense_Super_Compare_Results');
END

exec('exec dbo.Expense_Super_Compare');