Regroupements des modifications apportées à des lignes connexes à l'aide d'enregistrements logiques

Si le traitement de fusion est interrompu, par exemple en cas d'abandon de la connexion, le jeu partiellement exécuté de modifications répliquées liées est restauré lorsque vous utilisez les enregistrements logiques. Prenons l'exemple d'un Abonné qui ajoute une nouvelle commande (OrderID = 6) et deux nouvelles lignes dans la table OrderItems (OrderItemID = 10 et OrderItemID = 11) pour OrderID = 6.

Si le processus de réplication est interrompu après l'exécution de la ligne Orders de OrderID = 6 mais avant la fin de l'exécution de OrderItems 10 et 11 et que vous n'utilisez pas les enregistrements logiques, la valeur OrderTotal pour OrderID = 6 ne correspondra pas à la somme des valeurs OrderAmount des lignes OrderItems. Si vous utilisez les enregistrements logiques, la ligne Orders de OrderID = 6 n'est pas validée tant que les modifications de OrderItems liées ne sont pas répliquées.

Dans un autre scénario, si les enregistrements logiques sont utilisés et qu'un utilisateur interroge les tables pendant l'application de modifications par le processus de fusion, il ne voit les modifications partiellement répliquées qu'à partir du moment où elles sont toutes terminées. Imaginons que le processus de réplication a téléchargé la ligne Orders de OrderID = 6 mais qu'un utilisateur interroge les tables avant que le processus de réplication ait répliqué les lignes OrderItems : la valeur de OrderTotal ne correspondra pas à la somme des valeurs de OrderAmount. Si vous utilisez des enregistrements logiques, la ligne Orders ne sera pas visible tant que les lignes OrderItems ne sont pas terminées et que la transaction n'a pas été validée en tant qu'unité.

Envisageons le cas où deux Abonnés disposent du dataset ci-dessus :

• Un utilisateur du premier Abonné remplace la valeur 100 figurant dans OrderAmount de OrderItemID 5 par 150 et la valeur 200 figurant dans OrderTotal de OrderID 3 par 250.

• Un utilisateur du deuxième Abonné remplace la valeur 25 figurant dans OrderAmount de OrderItemID 6 par 125 et la valeur 200 figurant dans OrderTotal de OrderID 3 par 300.

Si ces modifications sont répliquées sans utiliser d'enregistrement logique, les différentes valeurs de OrderTotal se traduisent par un conflit et seule l'une d'elles est répliquée. Mais les modifications non conflictuelles apportées à la table OrderItems seront répliquées sans conflit, avec pour conséquence une incohérence des valeurs finales de OrderTotal par rapport aux lignes OrderItems. Si vous utilisez des enregistrements logiques dans ce scénario, la modification de OrderItems associée à la modification perdante de la table Orders sera également restaurée et la valeur finale de OrderTotal représentera la synthèse exacte des lignes OrderItems.

Pour plus d'informations sur les options relatives à la détection et à la résolution des conflits avec les enregistrements logiques, consultez Détection et résolution des conflits dans les enregistrements logiques.

• Il est recommandé de limiter au maximum le nombre de tables dans un enregistrement logique : cinq tables ou moins.

• Les enregistrements logiques ne peuvent pas référencer des colonnes contenant l'un des types de données suivants :

  • varchar(max) et nvarchar(max)

  • varbinary(max)

  • text et ntext

  • image

  • XML

  • UDT

• Les relations de clé étrangère dans les tables publiées ne peuvent pas être définies avec l'option CASCADE. Pour plus d'informations, consultez CREATE TABLE (Transact-SQL) et ALTER TABLE (Transact-SQL).

• Vous ne pouvez pas mettre à jour des colonnes utilisées dans la clause de relation logique.

• La résolution de conflits personnalisée avec des gestionnaires de logique métier ou des outils de résolution personnalisés n'est pas prise en charge pour les articles inclus dans un enregistrement logique.

• Si des enregistrements logiques sont utilisés dans une publication qui comprend des filtres paramétrés, vous devez initialiser chaque Abonné avec une capture instantanée de sa partition. Si vous initialisez un Abonné avec une autre méthode, l'Agent de fusion échoue. Pour plus d'informations, consultez Captures instantanées des publications de fusion avec des filtres paramétrés.

• Les conflits qui impliquent des enregistrements logiques ne s'affichent pas dans l'outil de résolution des conflits. Pour afficher des informations sur ces conflits, utilisez les procédures stockées de réplication. Pour plus d'informations, consultez Procédure : afficher les informations relatives aux conflits pour les publications de fusion (programmation Transact-SQL de la réplication).

• La publication doit présenter un niveau de compatibilité supérieur ou égal à 90RTM. Pour plus d'informations, consultez la section « Niveau de compatibilité de la publication » de Compatibilité descendante de la réplication.

• La publication doit utiliser le mode de capture instantanée natif. Ceci est le mode par défaut sauf lorsque vous effectuez une réplication vers SQL Server Compact 3.5 SP2, qui ne prend pas en charge les enregistrements logiques.

• La publication n'autorise pas la synchronisation Web. Pour plus d'informations sur la synchronisation Web, consultez Synchronisation Web pour la réplication de fusion.

• Pour utiliser des enregistrements logiques sur une publication filtrée :

  • Des partitions précalculées doivent également être utilisées. Les conditions requises associées aux partitions précalculées s'appliquent également aux enregistrements logiques. Pour plus d'informations, consultez Optimisation des performances des filtres paramétrés avec des partitions précalculées.

  • Vous ne pouvez pas utiliser de filtres paramétrés qui ne se chevauchent pas. Pour plus d'informations, consultez la section « Définition des options de partition » de Filtres de lignes paramétrés.

• Si la publication utilise des filtres de jointure, la propriété join unique key doit avoir la valeur true pour tous les filtres de jointure intervenant dans des relations d'enregistrement logique. Pour plus d'informations, consultez Filtres de jointure.

• Les tables liées par l'intermédiaire d'enregistrements logiques doivent avoir une relation clé primaire-clé étrangère.

• L'option NOT FOR REPLICATION ne peut pas être définie pour des contraintes de clé étrangère. Pour plus d'informations sur cette option, consultez Contrôle des contraintes, des identités et des déclencheurs avec l'option NOT FOR REPLICATION.

• Les tables enfants ne peuvent avoir qu'une table parent.

  Par exemple, une base de données effectuant un suivi des classes et des étudiants peut présenter une conception similaire à :

  

  Vous ne pouvez pas utiliser un enregistrement logique pour représenter les trois tables de cette relation car les lignes de ClassMembers ne sont pas associées à une ligne de clé primaire unique. Les tables Classes et ClassMembers peuvent néanmoins constituer un enregistrement logique, de même que les tables ClassMembers et Students mais pas les trois ensemble.

• La publication ne peut pas contenir des relations de filtre de jointure circulaires.

  Dans l'exemple des tables Customers, Orders et OrderItems, vous ne pourriez pas utiliser des enregistrements logiques si la table Orders possèdait également une contrainte de clé étrangère qui faisait référence à la table OrderItems.