Istruzioni UPDATE possono essere replicate come coppie DELETE/INSERT

Traduzione articoli Traduzione articoli
Identificativo articolo: 238254 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

Sommario

Se qualsiasi colonna che fa parte di un vincolo univoco viene aggiornato, quindi SQL Server implementa l'aggiornamento come "posticipato aggiornamento", ovvero come una coppia di DELETE / INSERT operazioni. Questo "aggiornamento differito" impedisce la replica inviare una coppia di DELETE o le istruzioni INSERT , agli utenti sottoscrittori. Esistono anche altre situazioni che potrebbero causare un aggiornamento posticipato. Di conseguenza, tutte le regole business che implementano nel trigger UPDATE o stored procedure personalizzate nel server di sottoscrizione anche devono essere incluso nel DELETE / INSERT trigger o stored procedure personalizzate.

Informazioni

Il comportamento predefinito nella replica transazionale consiste nell'utilizzare INSERT , UPDATE e DELETE stored procedure personalizzate per applicare modifiche ai sottoscrittori.

le istruzioni INSERT eseguite nel server di pubblicazione vengono applicate al server di sottoscrizione tramite una chiamata di procedura INSERT memorizzati. Analogamente, un'istruzione DELETE viene applicata tramite una chiamata di procedura DELETE memorizzati.

Tuttavia, quando viene eseguita un'istruzione di UPDATE come "posticipato aggiornamento", le posizioni di agente logreader una coppia di DELETE / INSERT memorizzati routine chiama nel database di distribuzione da applicare ai server di sottoscrizione, anziché un aggiornamento chiamata di stored procedure. Si supponga, ad esempio, di che avere una tabella di pubblicazione, denominata TABLE1, con queste tre colonne:
  • int Col1
  • int Col2
  • varchar(30) Col3.
Il vincolo univoco solo TABLE1 è definito in col1 tramite un vincolo di chiave primaria. Si supponga che un record (1,1, "Roma").

Quando si esegue questo codice:
UPDATE TABLE1 set col1 = 3 where col2 = 'Dallas'
				
nell'istruzione UPDATE viene implementato da SQL Server come una coppia di DELETE / le istruzioni INSERT dopo l'aggiornamento col1, che ha definito un indice univoco. Di conseguenza, il logreader inserisce una coppia di DELETE / INSERT chiama nel database di distribuzione. Ciò può influire sulle tutte le regole business che è presente nel trigger o stored procedure personalizzate nel server di sottoscrizione. È necessario incorporare la logica di business aggiuntive in trigger DELETE e INSERT o stored procedure per gestire questa situazione.

Se si preferisce utilizzare logica singola e tutti i comandi UPDATE replicati come DELETE che si desidera / INSERT coppie, è possibile attivare un flag di traccia come descritto in questo articolo della Knowledge Base riportato di seguito:
160181INF: Flag di traccia da replicare UPDATE come coppia DELETE/INSERT
Inoltre, se si utilizza un filtro orizzontale della pubblicazione e se la riga aggiornata non soddisfa una condizione di filtro, solo una DELETE chiamata di procedura invio agli utenti sottoscrittori. Se la riga aggiornata in precedenza non hanno soddisfatto la condizione di filtro ma soddisfa la condizione dopo l'aggiornamento, solo INSERT chiamata di routine viene inviata attraverso il processo di replica.

Nell'esempio precedente, si supponga che anche un filtro orizzontale definito in TABLE1: dove col2 = "Roma". Se si esegue questo codice:
UPDATE table1 set col2 = 'New York' where col1 = 3
				
le posizioni di solo agente logreader un DELETE chiamata di stored procedure da applicare ai sottoscrittori, poiché la riga aggiornata non soddisfa i criteri di filtro orizzontale.

Ora, se si esegue questo codice:
UPDATE table1 set col2 = 'Dallas' where col1 = 3
				
il logreader genera solo il INSERT memorizzati chiamata di routine, poiché la riga non hanno soddisfatto la condizione di filtro in precedenza.

Sebbene nel server di pubblicazione è stata eseguita un'operazione UPDATE , solo i comandi appropriati vengono applicati nel server di sottoscrizione.

Riferimenti

Per SQL Server 2000 Service Pack 1 o versione successiva, vedere il seguente articolo della Microsoft Knowledge Base riportato di seguito:
302341INF: Nuovo flag di traccia per attivare l'aggiornamento singleton per la replica transazionale

Proprietà

Identificativo articolo: 238254 - Ultima modifica: lunedì 12 maggio 2008 - Revisione: 6.2
Le informazioni in questo articolo si applicano a:
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
Chiavi: 
kbmt kbinfo KB238254 KbMtit
Traduzione automatica articoli
Il presente articolo è stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell?utente. Tuttavia, un articolo tradotto in modo automatico non è sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, più o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non è la sua. Microsoft non è responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell?utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.
Clicca qui per visualizzare la versione originale in inglese dell?articolo: 238254
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com