SQL Database Project: buduj różne skrypty w zależności od konfiguracji kompilacji.

Question

Problem, który chcę rozwiązać, polega na tworzeniu różnych skryptów w zależności od konfiguracji kompilacji.

że mamy dwie instancje SQL Server wersja

• przedsiębiorstwem z podłączonych serwerów połączonych
• wersja LocalDb dla zalogowany rozwój i jednostka testuje

wersja Enterprise ma widoki dla serwerów połączonych kiedy LocalDB zamienia te widoki na lokalne tabele.

Te widoki połączonego serwera i tabele lokalne mają te same nazwy i zestaw pól. Więc nie są one uwzględnione w kompilacji domyślnie (Build Action = None). Zamiast tego są one uwzględnione w wbudowanym pliku docelowym BeforeBuild pliku projektu.

<Target Name="BeforeBuild"> 

    <ItemGroup Condition=" '$(Configuration)' == 'LocalDb'"> 
     <Build Include="Local_Tables\*.sql" /> 
    </ItemGroup> 

    <ItemGroup Condition=" '$(Configuration)' != 'LocalDb' "> 
     <Build Include="Linked_Server_Views\*.sql" /> 
    </ItemGroup> 

</Target> 

ale problemem jest to, że Visual Studio buforuje Model DB i jeśli najpierw zbudować projekt dla LocalDb a następnie spróbować zbudować projektu dla konfiguracji Enterprise - Visual wyjścia Studio błędy:

Błąd: SQL71508: The model ma już element, który ma tę samą nazwę, co:

Jeśli chcesz zamknąć i otworzyć rozwiązanie lub Rozładuj projekt i przeładuj projekt, program Visual Studio odtwarza pliki dbmdl, a konfiguracja Enterprise jest tworzona bez błędów.

Tak więc moim założeniem jest, że jeśli odświeżę pamięć podręczną dbmdl, otrzymam płynną kompilację bez błędu.

---

Kiedy projekt otwarty lub przeładować SQL Server bazy danych w Visual Studio 2012, to tworzy plik z rozszerzeniem dbmdl, który jest rozszeregować i buforowane modelu db jak opisano here.

W momencie pliku dbmdl rekreacji Visual Studio generuje następujące:

Deserializing the project state for project 'MyProject.sqlproj'... 
Detecting file changes for project 'MyProject.sqlproj'... 
Deserialization has been completed for project 'MyProject.sqlproj'. 

Jak zmusić Visual Studio, aby odświeżyć pamięć podręczną dbmdl bez przeładowania projektu i bez zmiany pliku xml projektu?

Czy istnieje sposób na odświeżenie pamięci podręcznej dbmdl, umieszczając polecenie w docelowych obiektach BeforeBuild lub AfterBuild pliku xml projektu?

Albo całe podejście do problemu jest złe i istnieje inny sposób tworzenia różnych skryptów w zależności od konfiguracji kompilacji?

Answer 1

Możesz mieć inną możliwą opcję użycia projektów złożonych. Jamie Thompson napisał o nich na blogu: http://sqlblog.com/blogs/jamie_thomson/archive/2013/03/10/deployment-of-client-specific-database-code-using-ssdt.aspx

To pozwoli ci zbudować główny projekt i powiązać dodatkowe projekty z kodem specyficznym dla środowiska. Możesz wdrożyć odpowiedni, wykonując pewne kontrole w skryptach Release.

Answer 2

Myślałem o tym i najlepszym sposobie na radzenie sobie z SSDT. I prawdopodobnie nie ma „najlepszy” sposób, ale jeśli można określić poprawną wersję przed opublikowaniem zmian, Pomyślę o tym:

1. Tworzenie profilu publikowania dla każdej edycji - zi bez połączonych serwerów.
2. Twórz zmienne w celu przechowywania połączonych nazw serwerów, w miarę możliwości włączając w to bazę danych, na przykład "[Serwer].[Baza danych]. "
3. Utwórz skrypt po wdrożeniu dla połączonych widoków serwera, który powinien zawierać uprawnienia, zmienne dla połączonych nazw serwerów itd.
4. W skrypcie Post-Deploy zapytaj" edycja.Jeśli będzie używać serwerów połączonych, upuść/odtwórz macierzyste niepołączone widoki serwera w projekcie, aby użyć tych na połączonych serwerach .Alternatywnie, ustaw zmienną na pusty ciąg dla lokalnego widoku i serwera/DB dla połączonego serwera i prawdopodobnie możesz po prostu użyć jednego zestawu kodu:

Ma to tę wadę, że nie można sprawdzić kodu w widokach, ale dałoby to jedno miejsce do przechowywania połączonych widoków serwera i jedno miejsce e z których je wdrożyć. Musisz zwolnić przy użyciu polecenia Upuszczaj/Twórz zamiast zezwalać SSDT na obsługę zmian, co oznacza, że ​​zostaną ponownie utworzone przy każdej akcji publikowania. Myślę, że może ci dać rozwiązanie, którego szukasz.