Considerazioni sulla conservazione dei dati durante la distribuzione e gli aggiornamenti dello schema
Aggiornamento: novembre 2007
Prima di sincronizzare due schemi, è necessario configurare le impostazioni del progetto di database per ridurre il rischio che le modifiche provochino la perdita di dati importanti. Configurando tali impostazioni, è possibile bloccare la sincronizzazione se contiene modifiche che potrebbero rimuovere dati dal database di destinazione. Per ulteriori informazioni, vedere Procedura: controllare la perdita di dati durante la distribuzione in database esistenti e Procedura: impostare le opzioni per il confronto di schemi di database.
Tuttavia, questa impostazione può provocare risultati imprevisti. In alcune situazioni, impedisce la distribuzione delle modifiche anche quando non c'è il rischio che vadano perduti dati importanti. In altri casi, l'impostazione consente di distribuire le modifiche, anche se SQL Server potrebbe causare la perdita di dati quando la destinazione viene aggiornata.
Blocco non necessario di una distribuzione
Se si configurano le impostazioni del progetto per evitare la perdita di dati, potrebbe non essere possibile sincronizzare due schemi anche se nessun dato importante andrebbe perso. Ad esempio, è possibile eliminare una colonna di dati in un progetto di database e tentare di distribuire tale modifica al database di destinazione. Anche se la colonna è stata eliminata intenzionalmente, la distribuzione sarà bloccata per impedire la perdita di dati sulla destinazione.
Ad esempio, la distribuzione sarà bloccata se un tipo di dati nell'origine non può essere verificato come compatibile con l'equivalente tipo di dati nella destinazione. Questa situazione si può verificare quando l'origine o la destinazione contiene un tipo di dati definito dall'utente o un tipo Common Language Runtime (CLR). La distribuzione sarà bloccata se, ad esempio, un tipo di dati nell'origine è definito come char(100) ed il tipo di dati nella destinazione è definito come un tipo di dati definito dall'utente quale: CREATE TYPE [schema].[TipoDatiDefinitoDaUtente] FROM char(100) NOT NULL.
Se necessario, è possibile configurare temporaneamente le impostazioni del progetto per consentire la sincronizzazione dopo avere controllato lo script di distribuzione o di aggiornamento e verificato che le modifiche non provochino la perdita di dati importanti.
Perdita di dati durante la distribuzione sbloccata
Anche se si configura il progetto di database in modo da evitare la perdita di dati, SQL Server può, in alcuni casi, provocare la perdita di dati durante l'esecuzione della sincronizzazione. Prima di sincronizzare due schemi, è necessario verificare l'eventuale presenza degli elementi seguenti nello script di distribuzione o di aggiornamento:
Modifiche all'ordine delle colonne di una tabella.
Modifiche al tipo di dati di una colonna in un tipo non compatibile con un tipo di dati esistente e che utilizza tipi di dati nativi SQL. Questa situazione potrebbe verificarsi nel caso in cui una modifica al tipo di dati comporti un troncamento dei dati, ad esempio int a bit o nvarchar(100) a char(10).
Modifiche a una proprietà della colonna, ad esempio l'identità.
Modifiche alle proprietà di una colonna di identità di una tabella, ad esempio l'inizio identità.
Modifiche a una colonna che non consente valori NULL e che non ha alcun valore predefinito associato, ad esempio modificare una colonna per consentire valori null.
Modifiche a una colonna che non consente valori NULL quando la tabella contiene colonne aggiuntive associate alla colonna che si sta modificando.
Aggiunta di una colonna sulla quale è stata selezionata la casella di controlloImponi ordine delle colonne di tabella identico. Per ulteriori informazioni, vedere Opzioni (Strumenti di database/Confronto schema).
Modifiche al gruppo di file di una tabella.
Se lo script di distribuzione o di aggiornamento contiene questi tipi di modifiche, è possibile modificarlo manualmente per mantenere i dati.
Vedere anche
Attività
Procedura: controllare la perdita di dati durante la distribuzione in database esistenti
Procedura: distribuire modifiche in un database nuovo o esistente
Procedura: impostare le opzioni per il confronto di schemi di database
Procedura: sincronizzare gli schemi di database