Chi fra noi programmatori non ha mai avuto fatto un backup per portare un database da un'istanza all'altra di SQL server?
Purtroppo quando la cosa avviene da una versione più recente di SQL server ad una più vecchia non possiamo passare attraverso il backup. Purtroppo mamma Microsoft per scelta progettuale ci impedisce di fare ciò, anche se il backup fa riferimento ad un database in compatibilità con la versione precedente, e dobbiamo quindi aggirare il problema.
Poniamoci nella situazione di voler fare un ripristino di un backup eseguito con SQL 2012 su un'installazione SQL 2008. Dopo pochi secondi di avvio del tentativo di ripristino il tutto si bloccherà con un bel messaggio di errore, nonostante il db sia in compatibilità SQL 2008, e non c'è verso di riuscire a ripristinarlo e dobbiamo prendere tutta altra strada.
Se quello che ci interessa portare è la sola struttura del database senza dati è sufficiente far generare a Management Studio lo script di generazione di tutti gli oggetti del database e lanciarlo sull'istanza di destinazione, preoccupandoci ovviamente che lo script venga generato in compatibilità con la versione precedente.
Se invece dobbiamo anche portare i dati abbiamo davanti a noi due strade.
Se il numero di record è dell'ordine di grandezza delle migliaia possiamo includere nello script di generazione anche l'inserimento dei dati, altrimenti dobbiamo prendere la strada ben più macchinosa dell'importazione dati tabella per tabella.
In questo secondo scenario si pone il problema dell'integrità referenziale e dei continui errori dovuti proprio a questo fatto. Il consiglio per evitare continui errori e di farlo una tabella alla volta oppure disabilitare momentaneamente i vincoli per poi a fine lavoro riabilitarli in maniera tale da poterlo fare in sequenza automatica su tutte le tabelle.
Non dimentichiamo di abilitare anche l'IDENTITY INSERT per ogni tabella, altrimenti i dati o non vengono inseriti o peggio ancora vengono inseriti ma con chiavi nuove perdendo così tutte le relazioni.
Insomma è meglio non imbattersi in uno scenario di questo tipo ed assicurarsi che server di sviluppo e produzione abbiamo la stessa versione di SQL.