Progetto di database SQL: creare diversi script in base alla configurazione di build

Question

Il problema che voglio risolvere è creare script diversi a seconda della configurazione di build.

Supponiamo di avere due istanze di SQL Server: la versione

• Enterprise con i server collegati collegati
• versione LocalDB per offline lo sviluppo e l'unità di test

versione Enterprise dispone di una vista per i server collegato quando LocalDB sostituisce quelle viste con le tabelle locali.

Quelle viste Server collegati e le tabelle locali hanno gli stessi nomi e set di campi. Quindi non sono inclusi nella build di default (Build Action = None). Invece sono inclusi nella build di BeforeBuild Target del file di progetto.

<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> 

ma il problema è che Visual Studio memorizza nella cache del Modello DB e se prima di costruire progetti per LocalDB e quindi provare costruire progetto per la configurazione Enterprise - visivi uscite Studio errori:

Errore: SQL71508: I il modello ha già un elemento che ha lo stesso nome

Se per chiudere e aprire la soluzione o Unload Project e Ricarica progetto, Visual Studio ricrea i file dbmdl e la configurazione Enterprise viene creata senza errori.

Quindi la mia ipotesi è che se aggiorno la cache di dbmdl otterrò una build fluida senza errori.

---

Quando progetto di database SQL Server aperta o ricaricare in Visual Studio 2012, si crea un file con estensione dbmdl, che è un modello db deserializzati e memorizzato nella cache come descritto here.

Nel momento del file dbmdl ricreazione Visual Studio emette il seguente:

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

Come forzare Visual Studio per aggiornare la cache dbmdl senza progetto ricarica e senza cambiare il file xml progetto?

C'è un modo per aggiornare la cache dbmdl inserendo un comando nelle destinazioni BeforeBuild o AfterBuild del file xml di progetto?

Oppure l'intero approccio al problema è errato e c'è un altro modo per creare script diversi a seconda della configurazione di build?

Answer 1

Si può avere un'altra opzione possibile nell'utilizzo di progetti compositi. Jamie Thompson ha scritto su di loro qui: http://sqlblog.com/blogs/jamie_thomson/archive/2013/03/10/deployment-of-client-specific-database-code-using-ssdt.aspx

Questo ti consente di creare un progetto principale e legare in progetti aggiuntivi con il codice specifico dell'ambiente. È possibile distribuire quello appropriato eseguendo alcuni controlli negli script di rilascio.

Answer 2

Stavo pensando a questo e al modo migliore per gestirlo con SSDT. Probabilmente non ho un modo "migliore", ma se è possibile determinare la versione corretta prima di pubblicare le modifiche, mi piacerebbe prendere in considerazione questo:

1. Creare un profilo di pubblicazione per ogni edizione - con e senza server collegati.
2. Creare variabili per contenere i nomi dei server collegati, possibilmente includendo anche il database, quindi qualcosa come "[Server].[Database]. "
3. Creare uno script post-distribuzione per le visualizzazioni del server collegato, che dovrebbero includere autorizzazioni, le variabili per i nomi dei server collegati e così via.
4. Nello script Post-distribuzione, interrogare il proprio" variabile ". Se utilizzerà i server collegati, rilascia/ricrea le viste del server nativo non collegato nel progetto per utilizzare quelle sui server collegati. In alternativa, imposta la variabile su una stringa vuota per la vista locale e sul server/DB per il server collegato e probabilmente si può usare solo un set di codice

Questo ha lo svantaggio di non essere in grado di controllare il codice delle visualizzazioni, ma fornirebbe un posto per archiviare quelle viste server collegate e un posto e da cui distribuirli. Dovresti rilasciare con Drop/Create invece di lasciare che SSDT gestisca le modifiche, il che significa che verranno ricreate su ogni azione Pubblica. Penso che potrebbe darti la soluzione che stai cercando, però.