Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a:
SQL Server
Nota
Questa funzionalità verrà rimossa nelle versioni future di SQL Server. Evitare di usare questa funzionalità in un nuovo progetto di sviluppo e prevedere interventi di modifica nelle applicazioni in cui è attualmente implementata.
Utilizzando la replicazione tramite fusione, puoi specificare che i trigger di replicazione e le tabelle di sistema non tracciano le cancellazioni di uno o più articoli. Se selezioni questa opzione per un articolo, le cancellazioni non vengono tracciate o replicate dall'Publisher o da nessun Iscritto. Questa opzione supporta diversi scenari applicativi e fornisce un'ottimizzazione delle prestazioni nei casi in cui replicare le cancellazioni non è necessario o desiderabile. Le prestazioni sono migliorate in tre modi: il sistema non memorizza i metadati per le cancellazioni; non enumera le cancellazioni durante la sincronizzazione; e non replica le cancellazioni né le applica all'Abbonato.
Nota
Per utilizzare gli articoli solo download, il livello di compatibilità della pubblicazione deve essere almeno 90RTM.
Questa opzione può essere specificata alla creazione della pubblicazione oppure attivata e disattivata se un'applicazione richiede la replica di alcune eliminazioni e non di altre, ad esempio eliminazioni batch. Gli esempi seguenti illustrano le modalità di utilizzo di questa opzione in un'applicazione.
Un'applicazione per la forza vendita mobile in genere contiene tabelle come SalesOrderHeader, SalesOrderDetail e Product. Gli ordini vengono immessi nel Sottoscrittore e quindi replicati nell'Editore, che spesso fornisce i dati a un sistema di evasione ordini. Molti lavoratori mobili utilizzano dispositivi palmari che hanno una capacità di archiviazione limitata: quando l'ordine viene ricevuto nel server di pubblicazione, può essere eliminato nel Sottoscrittore. L'eliminazione non viene propagata al server di pubblicazione, perché l'ordine è ancora attivo nel sistema.
In questo scenario, le eliminazioni non verrebbero rilevate per le tabelle SalesOrderHeader e SalesOrderDetail . Le eliminazioni verrebbero tracciate per la tabella Product, perché se un prodotto viene eliminato nell'Editore, l'eliminazione deve essere inviata al Sottoscrittore per mantenere aggiornato l'elenco dei prodotti.
Un'applicazione potrebbe archiviare i dati storici in una tabella come TransactionHistory, da cui vengono periodicamente eliminati i record più vecchi di un anno. La tabella potrebbe essere filtrata in modo che i Sottoscrittori ricevano solo i dati delle transazioni del mese corrente. Le eliminazioni batch mensili del server di pubblicazione, con cui vengono eliminati i dati più vecchi, non interessano i Sottoscrittori, ma verrebbero comunque rilevate ed enumerate per impostazione predefinita.
In questo scenario, prima che abbia luogo l'elaborazione batch, sarebbe possibile arrestare l'attività del sistema e disabilitare il rilevamento delle eliminazioni dall'applicazione. Al termine dell'elaborazione, sarebbe possibile riabilitare la rilevazione.
Importante
Se nel server di pubblicazione prosegue l'attività, è necessario verificare che le eliminazioni che dovrebbero essere propagate ai Sottoscrittori non abbiano luogo mentre il rilevamento delle eliminazioni è disabilitato.
Per indicare che non si deve tenere traccia delle eliminazioni
- Programmazione Transact-SQL della replica: specificare le proprietà della replica di tipo merge