Instructions UPDATE peuvent être répliquées sous forme de paires DELETE/INSERT

Si la colonne qui fait partie d'une contrainte unique est mise à jour, puis SQL Server implémente la mise à jour en tant que «mise à différé jour», c'est-à-dire sous la forme d'une paire de DELETE / INSERT opérations. Cette «mise à différé jour"entraîne réplication pour envoyer une paire de DELETE / instructions INSERT aux abonnés. Il existe également d'autres situations susceptibles de provoquer une mise à jour différée. Donc, toute logique métier que vous implémentez dans votre déclencheurs UPDATE ou des procédures stockées personnalisées sur l'abonné doit également figurer au DELETE / INSERT des déclencheurs ou des procédures stockées personnalisées.

Dans la réplication transactionnelle, le comportement par défaut consiste à utiliser des procédures stockées personnalisées INSERT, UPDATE et DELETE pour appliquer les modifications sur les abonnés.

Instructions INSERT, effectuées sur l'éditeur sont appliquées aux abonnés par le biais d'un appel de procédure INSERT stockées. De même, une instruction DELETE est appliquée par l'intermédiaire d'un appel de procédure DELETE stockées.

Toutefois, lorsqu'une instruction UPDATE est exécutée comme un "différé update", les lieux de l'agent logreader une paire de DELETE / INSERT stockées procédure appelle dans la base de données de distribution à appliquer aux abonnés et non une mise à jour stockées appel de procédure. Par exemple, supposons que vous disposez d'une table de publication, nommée Table1, avec ces trois colonnes :

• Col1 int
• int col2
• Col3 varchar (30).

La contrainte d'unicité uniquement sur la TABLE1 est définie sur col1 par l'intermédiaire d'une contrainte de clé primaire. Supposons que vous possédez un seul enregistrement (1,1, ' Dallas').

Lorsque vous exécutez ce code : l'instruction UPDATE est implémentée par SQL Server en tant que paire de DELETE / instructions INSERT depuis que vous mettez à jour col1, possède un index unique défini. Par conséquent, la lecture du journal place une paire de DELETE / INSERT appelle dans la base de données de distribution. Cela peut avoir un impact sur toute logique métier est présent dans les déclencheurs ou des procédures stockées personnalisées sur l'abonné. Vous devez incorporer la logique métier supplémentaire de déclencheurs DELETE et INSERT ou les procédures stockées pour gérer cette situation.

Si vous préférez utiliser logique unique et que vous souhaitez toutes vos commandes UPDATE répliquées en tant que DELETE / INSERT paires, vous pouvez activer un indicateur de trace, comme décrit dans cet article de base de connaissances Microsoft : En outre, si vous utilisez un filtre horizontal dans votre composition et si la ligne mise à jour ne répond pas à une condition de filtre, uniquement un appel de procédure DELETE est envoyé aux abonnés. Si la ligne mise à jour ne respectait pas la condition de filtre précédemment mais répond à la condition après la mise à jour, uniquement l'appel de procédure INSERT envoyée par le processus de réplication.

Dans l'exemple précédent, supposons que vous possédez également un filtre horizontal défini sur la TABLE1 : où col2 = 'Dallas'. Si vous exécutez ce code : les logreader agent seuls endroits où un DELETE à appliquer aux abonnés dans la mesure où la ligne mise à jour ne répond pas aux critères de filtre horizontal de l'appel de procédure stockée.

Désormais, si vous exécutez ce code : le logreader génère uniquement l'appel de la procédure, l' INSERT stockée dans la mesure où la ligne ne respectait pas précédemment la condition du filtre.

Bien qu'une opération UPDATE a été effectuée au niveau de l'éditeur, uniquement les commandes appropriées sont appliquées côté abonné.

Pour SQL Server 2000 Service Pack 1 ou version ultérieure, consultez l'article suivant dans la base de connaissances Microsoft :