I dati del server di pubblicazione e quelli del Sottoscrittore non corrispondono

Le azioni seguenti consentono di identificare le cause elencate nella sezione "Spiegazione":

• I dati vengono aggiornati nel Sottoscrittore al di fuori della replica:

  • Se si desidera consentire agli utenti di inserire, aggiornare ed eliminare dati nel Sottoscrittore, utilizzare la replica di tipo merge, la replica transazionale con sottoscrizioni aggiornabili o la replica transazionale peer-to-peer. Per ulteriori informazioni, vedere Panoramica della replica di tipo merge e Tipi di pubblicazioni per la replica transazionale.

  • Se si desidera impedire agli utenti di inserire, aggiornare ed eliminare dati nel Sottoscrittore, creare un trigger per ogni tabella che contiene la parola ROLLBACK e utilizza l'opzione NOT FOR REPLICATION, che impedisce l'attivazione del trigger all'esecuzione di un'operazione da parte di un agente di replica). Ad esempio:

    USE AdventureWorks2008R2;
    GO
    CREATE TRIGGER prevent_user_dml
    ON Person.Address
    FOR INSERT, UPDATE, DELETE
    NOT FOR REPLICATION
    AS
    ROLLBACK;
    

    Per ulteriori informazioni, vedere CREATE TRIGGER (Transact-SQL) e Controllo di vincoli, identità e trigger con l'opzione NOT FOR REPLICATION.

• Nel Sottoscrittore vengono utilizzati i trigger. I trigger nel Sottoscrittore devono essere gestiti correttamente, per evitare la non convergenza o altri problemi:

  • È opportuno che i trigger causino modifiche di dati in un Sottoscrittore soltanto se si utilizza la replica di tipo merge, la replica transazionale con sottoscrizioni aggiornabili oppure la replica transazionale peer-to-peer. Per ulteriori informazioni, vedere Panoramica della replica di tipo merge e Tipi di pubblicazioni per la replica transazionale.

  • In molti casi, i trigger devono utilizzare l'opzione NOT FOR REPLICATION. Si consideri un trigger che inserisce i dati in una tabella di rilevamento: quando l'utente inserisce la riga inizialmente, è giusto che il trigger si attivi e inserisca una riga nella tabella di rilevamento, ma non deve attivarsi quando i dati vengono replicati nel Sottoscrittore, perché questo provocherebbe l'inserimento di una riga superflua nella tabella di rilevamento.

    Se un trigger include un'istruzione ROLLBACK e non utilizza l'opzione NOT FOR REPLICATION, è possibile che le righe che replicate in un Sottoscrittore non vengano applicate.

  • Per la replica transazionale, vi sono altre considerazioni relative all'impostazione XACT_ABORT e all'uso delle istruzioni COMMIT e ROLLBACK in un trigger. Per ulteriori informazioni, vedere la sezione relativa ai trigger in Considerazioni sulla replica transazionale.

• Gli script vengono eseguiti nella replica nel Sottoscrittore ma non nel server di pubblicazione.

  I parametri @pre_snapshot_script e @post_snapshot_script di sp_addpublication e sp_addmergepublication consentono di specificare gli script da eseguire prima e dopo l'applicazione dello snapshot. Per ulteriori informazioni, vedere Esecuzione di script prima e dopo l'applicazione dello snapshot. La stored procedure sp_addscriptexec consente di eseguire uno script durante il processo di sincronizzazione. Per ulteriori informazioni, vedere Procedura: Esecuzione di script durante la sincronizzazione (programmazione Transact-SQL della replica).

  Questi script vengono in genere utilizzati per le attività di amministrazione, come l'aggiunta degli account di accesso nel Sottoscrittore. Se gli script vengono utilizzati per aggiornare dati in un Sottoscrittore che andrebbe considerato di sola lettura, l'amministratore deve accertarsi che non si generi una non convergenza.

• La replica dell'esecuzione di una stored procedure per la pubblicazione transazionale produce risultati diversi nel Sottoscrittore.

  Se si replica l'esecuzione di un stored procedure, la definizione della procedura viene replicata nel Sottoscrittore quando viene inizializzata la sottoscrizione. Quando la procedura viene eseguita nel server di pubblicazione, la replica esegue la procedura corrispondente nel Sottoscrittore. Per ulteriori informazioni, vedere Pubblicazione dell'esecuzione delle stored procedure nella replica transazionale.

  Se la stored procedure completa un'azione diversa nel Sottoscrittore oppure viene eseguita su dati diversi rispetto al server di pubblicazione, si può riscontrare la non convergenza. Si consideri una procedura che esegue un calcolo e quindi inserisce dati basati su tale calcolo. Se il Sottoscrittore viene filtrato in modo che i dati nello stesso si basino su altri dati, il risultato inserito nel Sottoscrittore può essere diverso o l'inserimento può non avere affatto luogo.

• Le violazioni di vincoli o altri problemi impediscono l'inserimento, l'aggiornamento o l'eliminazione di righe nel Sottoscrittore.

  Per la replica transazionale, le violazioni di un vincolo sono considerate errori. Per impostazione predefinita provocano l'arresto della sincronizzazione da parte dell'agente di distribuzione (per informazioni su come ignorare questi errori, vedere Errori da ignorare nella replica transazionale). Per la replica di tipo merge, le violazioni dei vincoli vengono considerate come conflitti. Vengono registrate, ma non determinano l'arresto della sincronizzazione da parte dell'agente di merge. Per entrambi i tipi di replica, le violazioni dei vincoli possono causare la non convergenza se un'operazione di inserimento, aggiornamento o eliminazione viene completata in un nodo ma non in un altro.

  Quando una tabella viene pubblicata, le opzioni predefinite dello schema specificano che nel database di sottoscrizione devono essere creati vincoli FOREIGN KEY e vincoli CHECK con l'opzione NOT FOR REPLICATION impostata. Se l'applicazione richiede impostazioni diverse per i vincoli, modificare le opzioni dello schema. Per ulteriori informazioni, vedere Procedura: Impostazione delle opzioni dello schema (SQL Server Management Studio) e Procedura: Impostazione delle opzioni dello schema (programmazione Transact-SQL della replica).