Panoramica della replica di tipo merge

In genere la replica di tipo merge, come la replica transazionale, inizia con uno snapshot degli oggetti e dei dati del database di pubblicazione. Eventuali modifiche dei dati e dello schema apportate successivamente nel server di pubblicazione e nei Sottoscrittori vengono rilevate tramite trigger. Al momento della connessione alla rete il Sottoscrittore esegue la sincronizzazione con il server di pubblicazione e scambia con esso le righe modificate dopo l'ultima sincronizzazione.

In genere la replica di tipo merge è utilizzata in ambienti server-to-client. La replica di tipo merge è adatta alle seguenti situazioni:

• Più Sottoscrittori potrebbero richiedere l'aggiornamento dei dati in ore diverse e la distribuzione delle modifiche al server di pubblicazione e ad altri Sottoscrittori.

• I Sottoscrittori devono ricevere i dati, eseguire le modifiche offline e sincronizzarle successivamente con il server di pubblicazione e i Sottoscrittori.

• Per ogni Sottoscrittore è necessaria una diversa partizione di dati.

• È necessario essere in grado di individuare e risolvere tempestivamente eventuali conflitti che potrebbero verificarsi.

• È necessario lo scambio di dati net piuttosto che l'accesso a stati di dati intermedi. Ad esempio, se una riga viene modificata cinque volte nel Sottoscrittore prima della sincronizzazione con un server di pubblicazione, la riga verrà modificata solo una volta nel server di pubblicazione per riflettere la modifica dei dati net, ovvero il quinto valore.

La replica di tipo merge consente a vari siti di eseguire elaborazioni in modo autonomo e di unire quindi gli aggiornamenti in un unico risultato uniforme. Dato che gli aggiornamenti vengono eseguiti in più nodi, è possibile che dati uguali siano aggiornati dal server di pubblicazione e da più Sottoscrittori, con la conseguente possibilità di conflitti quando viene eseguito il merge degli aggiornamenti. Con la replica di tipo merge vengono tuttavia offerti diversi modi di risoluzione dei conflitti.

Per tener traccia delle modifiche, la replica di tipo merge e la replica transazionale con sottoscrizioni ad aggiornamento in coda devono essere in grado di identificare in modo univoco ogni riga di ciascuna tabella pubblicata. A tal fine, tramite la replica di tipo merge viene aggiunta la colonna rowguid a ogni tabella, a meno che in quest'ultima non sia già presente una colonna del tipo di dati uniqueidentifier con il set di proprietà ROWGUIDCOL; in tal caso, viene utilizzata questa colonna. Se la tabella viene rimossa dalla pubblicazione, la colonna rowguid viene eliminata; se per il rilevamento è stata utilizzata una colonna esistente, questa non viene eliminata. In un filtro non deve essere incluso il set di proprietà rowguidcol utilizzato dalla replica per identificare le righe. La funzione newid() viene fornita come impostazione predefinita per la colonna rowguid, tuttavia, se necessario, i clienti possono fornire un GUID per ogni riga, ad eccezione del valore 00000000-0000-0000-0000-000000000000.

Per informazioni sull'implementazione della replica di tipo merge, vedere Progettazione e implementazione (Replica).

Per informazioni sugli scenari più comuni relativi alla replica di tipo merge, vedere Replica di dati tra server e client.