Modification du schéma dans les bases de données de publication

• Les modifications de schéma sont soumises aux restrictions imposées par Transact-SQL. Par exemple, ALTER TABLE ne vous permet pas de modifier les colonnes de clés primaires.

• Le mappage de type de données est effectué uniquement pour la capture instantanée initiale. Les modifications de schéma ne sont pas mappées aux versions précédentes des types de données. Par exemple, si l'instruction ALTER TABLE ADD datetime2 column est utilisée dans SQL Server 2008, le type de données n'est pas traduit par nvarchar pour les Abonnés SQL Server 2005. Dans certains cas, les modifications de schéma sont bloquées sur le serveur de publication.

• Si la configuration d'une publication autorise la propagation des modifications de schéma, celles-ci sont propagées quelle que soit la configuration de l'option de schéma associée pour un article de la publication. Si, par exemple, vous décidez de ne pas répliquer les contraintes de clé étrangère pour un article de table mais qu'ensuite vous émettez une commande ALTER TABLE qui ajoute une clé étrangère sur le serveur de publication, la clé étrangère est ajoutée à la table sur l'Abonné. Pour éviter cela, désactivez la propagation des modifications de schéma avant d'émettre la commande ALTER TABLE.

• Les modifications de schéma doivent être uniquement effectuées sur le serveur de publication et non sur les Abonnés (y compris les Abonnés de republication). La réplication de fusion interdit les modifications de schéma sur l'Abonné, à la différence de la réplication transactionnelle mais dans ce dernier cas, il se peut que les modifications apportées entraînent l'échec de la réplication.

• Les modifications propagées à un Abonné de republication sont transmises par défaut à ses Abonnés.

• Si la modification de schéma fait référence à des objets ou des contraintes qui existent sur le serveur de publication mais pas sur l'Abonné, elle est effectuée sur le serveur de publication mais échoue sur l'Abonné.

• Tous les objets de l'Abonné référencés lors de l'ajout d'une clé étrangère doivent avoir un nom et un propriétaire identiques à l'objet correspondant sur le serveur de publication.

• L'ajout, la suppression ou la modification explicites d'index ne sont pas pris en charge. En revanche, les index créés explicitement pour les contraintes, par exemple une contrainte de clé primaire, le sont.

• La modification ou la suppression de colonnes d'identité gérées par la réplication ne sont pas prises en charge. Pour plus d'informations sur la gestion automatique des colonnes d'identité, consultez Réplication de colonnes d'identité.

• Les modifications de schéma qui comprennent des fonctions non déterministes ne sont pas prises en charge car elles peuvent se traduire par la présence de données différentes sur le serveur de publication et l'Abonné (c'est-à-dire non convergentes). Par exemple, si vous émettez la commande suivante sur le serveur de publication : ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE(), les valeurs diffèrent lorsque la commande est répliquée sur l'Abonné, puis exécutée. Pour plus d'informations sur les fonctions non déterministes, consultez Fonctions déterministes et non déterministes.

• Il est conseillé de nommer explicitement les contraintes. Si les contraintes ne sont pas nommées explicitement, SQL Server génère des noms pour celles-ci, qui seront différents sur le serveur de publication et sur chaque Abonné. Cela peut occasionner des problèmes pendant la réplication des modifications de schéma. Par exemple, si vous supprimez une colonne sur le serveur de publication et qu'une contrainte dépendante est supprimée, la réplication essaie de supprimer la contrainte sur l'Abonné. La suppression sur l'Abonné échouera car le nom de la contrainte est différent. Si la synchronisation échoue en raison d'un problème de dénomination de contrainte, supprimez manuellement la contrainte sur l'Abonné, puis réexécutez l'Agent de fusion.

• Si une table est publiée pour la réplication, il n'est pas possible de modifier une colonne de cette table en lui attribuant un type de données XML si une capture instantanée de publication a déjà été générée. Pour modifier la colonne, vous devez d'abord supprimer la réplication. Pour plus d'informations, consultez Suppression de la réplication.

Ajout de colonnes

Suppression de colonnes

• Les modifications de schéma sont propagées aux Abonnés exécutant des versions antérieures de SQL Server, mais l'instruction DDL doit absolument inclure la syntaxe prise en charge par la version installée sur l'Abonné.

  Si l'Abonné republie des données, les seules modifications de schéma prises en charge sont l'ajout et la suppression d'une colonne. Ces modifications doivent être apportées au serveur de publication à l'aide de sp_repladdcolumn (Transact-SQL) et de sp_repldropcolumn (Transact-SQL) au lieu de la syntaxe DDL ALTER TABLE.

• Les modifications de schéma ne sont pas répliquées sur les abonnés SQL Server.

• Ces modifications ne sont pas propagées si elles proviennent de serveurs de publication non SQL Server.

• Vous ne pouvez pas modifier des vues indexées répliquées en tant que tables. Les vues indexées répliquées en tant que vues indexées peuvent l'être mais une fois modifiées, elles deviennent des tables régulières et non plus des vues indexées.

• Si la publication prend en charge les abonnements avec mise à jour immédiate ou les abonnements avec mise à jour en attente, le système doit être suspendu avant toute modification du schéma : toutes les activités relatives à la table publiée doivent être interrompues au niveau du serveur de publication et des Abonnés. Par ailleurs, les modifications de données en attente doivent être propagées à tous les nœuds. Après la propagation des modifications de schéma à tous les nœuds, l'activité peut reprendre dans les tables publiées.

• Si la publication fait partie d'une topologie d'égal à égal, le système doit être suspendu le temps d'effectuer les modifications de schéma : Pour plus d'informations, consultez Procédure : suspendre une topologie de réplication (programmation Transact-SQL de la réplication).

• L'ajout d'une colonne d'horodatage à une table et le mappage de l'horodatage à binary(8) entraîne la réinitialisation de l'article pour tous les abonnements actifs.

• La façon dont la réplication de fusion gère des modifications de schéma est déterminée par le niveau de compatibilité de la publication et le fait que la capture instantanée soit définie en mode natif (par défaut) ou en mode caractère :

  • Pour répliquer les modifications de schéma, le niveau de compatibilité de la publication doit être au minimum égal à 90RTM. Si les Abonnés exécutent des versions antérieures de SQL Server ou si le niveau de compatibilité est inférieur à 90RTM, vous pouvez utiliser sp_repladdcolumn (Transact-SQL) et sp_repldropcolumn (Transact-SQL) pour ajouter et supprimer des colonnes. Toutefois, ces procédures sont désapprouvées.

  • Si vous essayez d'ajouter à un article existant une colonne avec un type de données qui a été introduit dans SQL Server 2008, SQL Server présente le comportement suivant :

    	100RTM, capture instantanée native	100RTM, capture instantanée en mode caractère	Tous les autres niveaux de compatibilité
    hierarchyid	Autoriser la modification	Bloquer la modification	Bloquer la modification
    geography et geometry	Autoriser la modification	Autoriser la modification1	Bloquer la modification
    filestream	Autoriser la modification	Bloquer la modification	Bloquer la modification
    date, time, datetime2 et datetimeoffset	Autoriser la modification	Autoriser la modification1	Bloquer la modification

    1 Les Abonnés SQL Server Compact convertissent ces types de données côté Abonné.

  Pour plus d'informations sur la compatibilité de la publication, consultez la section « Niveau de compatibilité des publications de fusion » dans Utilisation de plusieurs versions de SQL Server dans une topologie de réplication.

• Si une erreur se produit lors de l'application d'une modification de schéma (par exemple une erreur résultant de l'ajout d'une clé étrangère référençant une table non disponible sur l'Abonné), la synchronisation échoue et l'abonnement doit être réinitialisé.

• Si une modification de schéma est apportée à une colonne reprise dans un filtre de jointure ou un filtre paramétré, vous devez réinitialiser tous les abonnements et régénérer la capture instantanée.

• La réplication de fusion fournit des procédures stockées qui permettent d'ignorer les modifications de schéma pendant le dépannage. Pour plus d'informations, consultez sp_markpendingschemachange (Transact-SQL) et sp_enumeratependingschemachanges (Transact-SQL).