2010-05-19 11 views
7

Ho appena iniziato a utilizzare un progetto di database VS2010 per gestire il rilascio di un aggiornamento in un database esistente.Come posso impostare le opzioni di distribuzione per eseguire lo script della versione incrementale di un progetto di database di Visual Studio 2010?

Desidero che l'opzione di implementazione generi uno script che conterrà i comandi per modificare il database esistente anziché crearne uno completamente nuovo.

E.g Ho 10 tabelle esistenti, una delle quali rilascia la nuova versione e creo alcuni nuovi sproc. Voglio solo che la distribuzione copi i comandi Drop Table e Create Procedure.

Sto usando VS2010 Premium.

Esiste un approccio standard consigliato che potrei seguire per gestire i DB in un progetto dalla creazione iniziale a versioni incrementali?

Grazie!

risposta

5

C'è un "Sempre ricreare il database" nel file .sqldeployment del progetto. Se si deseleziona questa opzione, verrà generato uno script SQL generato automaticamente che aggiornerà il database in modo incrementale senza prima eliminarlo.

Esiste anche un'opzione per "Generare istruzioni DROP per gli oggetti presenti nel databse di destinazione ma che non si trovano nel progetto del database." Dovrai controllare questa opzione, se vuoi che le tabelle, i proc memorizzati ecc. Vengano eliminati se li hai cancellati nel progetto del database. Questo eliminerà qualsiasi tabella, ecc. Che gli utenti potrebbero aver creato da solo per test, debug, ecc.

Per modificare le opzioni nel file .sqldeployment. Apri il file in Visual Studio. Espandere il progetto del database in Solution Explorer, fare doppio clic sul file .sqldeployment (probabilmente si troverà nella cartella Proprietà del progetto DB). Oppure apri la pagina delle proprietà per il progetto del database e fai clic sul pulsante "Modifica ..." accanto al "File di configurazione della distribuzione". Seleziona o deseleziona le opzioni che desideri quando il database viene distribuito.

Io uso VSDBCMD.exe per 1-click build & distribuire gli script che ho creato. Funziona molto bene. VSDBCMD utilizza un file .sqldeployment: il file .sqldeployment predefinito viene specificato nel file .deploymanifest, ma può essere sovrascritto specificandolo come parametro durante l'esecuzione di VSDBCMD.Inoltre, credo che Visual Studio utilizzi VSDBCMD sotto le copertine quando distribuisce il progetto del database, ma presumo che sia il caso poiché la funzionalità è praticamente identica.

+0

Grazie per l'informazione Adam. Come vorresti quindi tenere traccia di ogni versione del DB durante la sua vita? Ad esempio, se ho rilasciato la versione 5 del DB, come posso eseguire il rollback alla versione 3? Devo salvare uno script di una linea di base e quindi salvare ciascuno di questi script di aggiornamento incrementale generati automaticamente? – littlechris

+1

Aggiungiamo tutti i file SQL nel progetto DB VS2010 al controllo della versione e usiamo le etichette per tracciare ogni versione. Per eseguire il rollback alla versione 3, esegui la sincronizzazione con l'etichetta v3. Dovresti davvero usare la versione per il controllo del tuo database. Jeff Atwood ha scritto 2 articoli di blog sul controllo della versione del database che consiglio di leggere Il tuo database è sotto controllo di versione? zttp: //www.codinghorror.com/blog/2006/12/is-your-database-under-version-control.html Ottieni il tuo database con il controllo della versione http://www.codinghorror.com/blog/2008 /02/get-your-database-under-version-control.html –

4

Ho fatto una domanda simile qualche tempo fa su MSDN Forums e mi è stato detto che il modo consigliato per farlo è usare VSDBCMD. In sostanza, si genera un file di schema dal progetto di database che contiene tutte le informazioni sul database e quindi si esegue VSDBCMD per confrontare lo schema con il database di destinazione. Questo a sua volta crea lo script per aggiornare il database di destinazione allo schema corrente.

La logica di questo approccio è che solo perché tu e io potremmo pensare di sapere come appare lo schema del database di destinazione, non possiamo essere sicuri fino a quando non consentiremo a VSDBCMD di eseguire il confronto. Chissà, qualcun altro potrebbe aver modificato lo schema nel database di destinazione a nostra insaputa, quindi il nostro script di modifica potrebbe non riuscire per qualche motivo sconosciuto.

Non ero davvero soddisfatto di questo approccio e ho continuato a usare il mio "vecchio approccio" di codifica manuale dei miei script di cambiamento quando necessario, ma sono ansioso di vedere se qualcosa è cambiato nel 2010 che rende questo un po 'più facile da lavorare. Mi piacerebbe davvero vedere una semplice API che fa ciò che VSDBCMD fa, quindi posso mettere insieme una GUI per semplificare l'aggiornamento di un database di destinazione (nel mio caso, client) senza che la persona che esegue l'aggiornamento debba essere un DBA.

Problemi correlati