Pourquoi la réplication de fusion échoue-t-elle lors de la définition de LOCK_ESCALATION d'une table?

Question

Nous avons un problème avec une réplication de fusion. Notre éditeur exécute SQL Server 2008, tandis que nos deux abonnés exécutent 2005. Notre éditeur tente d'envoyer une commande ALTER TABLE Foo SET (LOCK_ESCALATION) à nos abonnés. Je pense me souvenir d’avoir lu que cette commande est nouvelle dans SQL Server 2008 et, dans l’affirmative, il est logique que la commande échoue sur nos serveurs 2005. Notre réplication de fusion est toutefois configurée pour la compatibilité 2005.

  

Le script de schéma 'si object_id (N' [dbo]. [Utilisateurs] ') n'est pas null exec (' ALTER TABLE [dbo]. [Utilisateurs] SET (LOCK_ESCALATION = TABLE)   ')' n'a pas pu être propagé à l'abonné.

Avez-vous des idées sur les raisons pour lesquelles notre éditeur essaie de le faire?

Modifier: Le niveau de compatibilité de notre serveur 2008 est défini sur "SQL Server 2005 (90)"

.

Answer 1

C’est une nouvelle fonctionnalité de SQL 2008, elle n’est donc pas prise en charge en 2005. En fonction de la complexité de votre configuration, vous pouvez envisager de faire fonctionner votre base de données en compatibilité 90 (SQL 2005) afin d’éviter d’ajouter des fonctionnalités SQL 2008 à votre système. base de données. Vous avez eu de gros problèmes avec la réplication des données de schéma depuis qu’elle est apparue, alors restez un peu réticent. J'essaie toujours de le rendre idiot et juste de gérer les données - je devais supporter un système de fusion avec 32 abonnés avec réplication de fusion et j'avais de gros problèmes de schéma constamment lorsque nous demandions des modifications de schéma.

Cela dit, si cela fonctionne de la manière documentée, vous ne devriez pas essayer de pousser votre changement de verrou. Vérifiez que les abonnements sont marqués comme étant compatibles avec SQL 2005. Il est probable qu’ils n’ont pas créé de mappage automatique du paramètre de 2008 à 2005 comme ils l’ont fait pour les types de données (par exemple)

L'un des développeurs SQL blogué sur les nouveaux types de verrouillage il y a quelque temps

Answer 2

Cela est dû à l'incompatibilité de cette instruction avec SQL Server 2005 et, bien entendu, lorsque je modifie un schéma dans une table en cours de réplication, cette instruction est incluse dans les modifications du schéma.

Il existe deux méthodes: supprimer et créer à nouveau la souscription, non applicable dans le serveur de production. La deuxième méthode consiste à accéder à la table sysmergeschemachange dans la base de données et à supprimer la ligne contenant quelque chose comme ceci:

  

Le script de schéma 'si   object_id (N '[dbo]. [Users]') n'est pas   null exec ('ALTER TABLE [dbo]. [Utilisateurs]   SET (LOCK_ESCALATION = TABLE) ')'   ne pourrait pas être propagé à la   abonné.

J'espère que cela vous aidera.