MS SQL Server
  1. MS SQL Server
  3. Pourquoi la réplication de fusion échoue-t-elle lors de la définition de LOCK_ESCALATION?
Intereting Posts
Exécutez la procédure stockée SQL pour chaque valeur d'un tableau SQL Server Management Syntaxe Sql Server XQuery transforme xml dans la clause select Installation de SQL Server Express 2014 avec Wix Burn Devrais-je être inquiet si une sous-requête renvoie trop de données? erreur de caractères spéciaux dans sql lors de la soumission du formulaire summernote Une expression de type non boolean spécifiée dans un context où une condition est attendue, près de 'NAME'. ' Nouvelle ligne dans Constante lors de l'affectation d'une valeur à une string à l'aide de plusieurs lignes Pics de DTU soudains dans Azure SQL l'utilisation de jointures combine deux ou plusieurs tables dans une même table ADO – Puis-je modifier les résultats d'une requête complexe avec plusieurs instructions de jointure? Meilleures pratiques pour déplacer une database de Dev / Test à Prod Requêtes de database agrégées conditionnelles et leurs implications en termes de performances Que fait une transaction autour d'une seule déclaration? Comment get tous les nombres entre une gamme

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

Nous avons un problème avec une réplication de fusion. Notre éditeur exécute SQL Server 2008, tandis que nos deux abonnés s'exécutent en 2005. Notre éditeur tente d'envoyer une command ALTER TABLE Foo SET (LOCK_ESCALATION) à nos abonnés. Je pense que je me souviens avoir lu que cette command est nouvelle dans SQL Server 2008, et si c'est le cas, il est logique que la command échoue sur nos servers 2005. Notre réplication de fusion est configurée pour la compatibilité 2005, cependant.

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

Des idées sur la raison pour laquelle notre éditeur essaierait de le faire?

Edit: le niveau de compatibilité de notre server 2008 est défini sur "Sql Server 2005 (90)"

Il s'agit d'une nouvelle fonctionnalité de SQL 2008 non prise en charge en 2005. Selon la complexité de votre configuration, vous pouvez envisager de faire fonctionner votre database en compatibilité 90 (sql 2005) pour vous assurer de ne pas append de fonctionnalités SQL 2008 à votre database. Avoir eu de gros problèmes avec la réplication des données de schéma depuis qu'il est arrivé, donc toujours un peu réticent. J'essaie toujours de le rendre idiot et de gérer simplement datatables – il fallait supporter un système de fusion avec 32 abonnés avec une réplication de fusion et avoir de gros problèmes de schémas constamment quand nous avons poussé les changements de schémas.

Cela dit, si cela fonctionne comme documenté, il ne devrait pas essayer de pousser votre changement de serrure. Vérifiez que les abonnements sont marqués comme compatibles avec SQL 2005. Il est probable qu'ils n'ont pas créé une carte automatique du paramètre de 2008 à 2005 comme ils l'ont fait pour les types de données (par exemple)

Un des développeurs de SQL a blogué sur les nouveaux types de locking il y a quelques time

Cela se produit parce que l'incompatibilité de cette instruction avec sql server 2005 et régulièrement lorsque je fais un changement de schéma dans une table qui se réplique met cette instruction dans le schéma change.

Il y a deux façons: Supprimer et créer de nouveau l'abonnement, non applicable lorsque c'est dans le server de production. La deuxième façon est d'aller à la table sysmergeschemachange dans la database et de supprimer la ligne qui a quelque chose comme ceci:

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

J'espère que ça aide.