Compilazione condizionale della procedura memorizzata di SQL Server

Versione breve: esiste un modo per compilare in modo condizionale blocchi di codice TSQL in un progetto dati di SQL Server utilizzando SQL Server Data Tools per Visual Studio 2010?

Sto usando SQL Server Data Tools in Visual Studio 2010 per lavorare su un database sperimentale di SQL Server Express. La destinazione finale se le cose funzionano bene sarebbe una piattaforma SQL Server aziendale. Ho sia un'istanza del 2008 in una casella che un'istanza del 2012 in un'altra, perché la mia azienda è in procinto di migrare dal 2008 al 2012 anche per i numerosi database aziendali.

In altri linguaggi di programmazione che ho usato, le direttive del preprocessore facilitano la compilazione condizionale di parti di una base di codice. Gli usi più comuni per questo sono avere codice diverso per piattaforme diverse in sezioni riservate o escludere il codice di output di debug dalle build di rilascio .

Entrambi potrebbero essere molto utili in alcune procedure di negozio su cui sto lavorando. C'è qualcosa di simile disponibile? So di poter utilizzare le sqlcmdvariabili per scambiare valori specifici durante la distribuzione, ma non riesco a capire come utilizzarlo per includere o escludere blocchi di codice successivi.

Esempio:

#IF $(DebugVersion) = 'True'
    -- A bunch of useful PRINTs and what not
#ELSE
    SET NOCOUNT ON
#ENDIF

#IF $(SSVersion) = '2012'
    SET @pretty_date = FORMAT(@some_date, 'dddd, MMM dd, yyyy')
#ELSE
    SET @pretty_date = CAST(@some_date AS nvarchar(12))
#ENDIF

Purtroppo non sono a conoscenza di questo possibile con SSDT.

A seconda di quanto è grande il progetto e di quante procedure intendi migliorare con le chicche del 2012, potrebbe essere gestibile con i progetti compositi .

SSDT può combinare un progetto di database con uno o più progetti di database di riferimento o dacpac per descrivere un singolo schema di database composito. L'uso di un progetto composito consente di suddividere un database di grandi dimensioni in blocchi più gestibili, consente a persone o team diversi di avere la responsabilità delle diverse parti dello schema generale e consente il riutilizzo delle definizioni degli oggetti del database in più database.

L'idea sarebbe quella di avere un progetto di base, contenente le definizioni degli oggetti comuni e i progetti specifici della versione per le procedure che utilizzavano nuove funzionalità. Il progetto 2012 farebbe riferimento al progetto base e una compilazione / compilazione combinerebbe oggetti di entrambi.

Il PITA sarebbe che non è possibile sostituire un oggetto nel progetto di base con un oggetto in un composito, quindi è necessario mantenere i progetti di base, 2008 e 2012. Quando si desidera una versione 2012 di una determinata procedura, è necessario rimuoverla dalla base e creare una versione in entrambi i progetti 2008 e 2012.

Ho avuto una discussione aperta su MSDN su questa esigenza. Non hanno fatto molti progressi. La situazione ideale consentirebbe di contrassegnare gli oggetti db come "ereditabili" nei progetti ssdt di base in modo che altri progetti che fanno riferimento al progetto di base o al DAC non si lamentino dell'oggetto duplicato e creerebbero l'oggetto di base o "stub" solo se non esisteva. Ciò consentirebbe di avere "livelli" di modelli di database. Vedi il mio post su msdn Estensione delle soluzioni composite SSDT con Overriden Stored Procedures

Ho ottenuto qualcosa di simile a ciò che viene chiesto utilizzando eventi pre-build. Nel mio caso, volevo che diversi utenti e accessi fossero inclusi in una distribuzione in base alla configurazione che veniva costruita.

Per fare ciò ho creato un file .sql per ciascuna configurazione build, per ciascun utente. Li ho contrassegnati come Build None 'Nessuno': (li ho inseriti in una sottocartella del progetto)

• Debug_SomeUser.sql
• Release_SomeUser.sql

Ho quindi creato un file vuoto SomeUser.sql (con Build Action = 'Build').

Nella riga di comando dell'evento Pre-build:

Copy $(ProjectDir)subfolder\$(Configuration)_Someuser.sql $(ProjectDir)Someuser.sql

Era una seccatura che un team di programmatori creava costantemente conflitti in git, quindi ho anche aggiunto alla riga di comando pre-build

git update-index --assume-unchanged $(ProjectDir)Someuser.sql 

È stato abbastanza complicato farlo funzionare dato che avevo un numero molto più grande di utenti e configurazioni da considerare, ma funziona.