Perché la replica di tipo merge non riesce quando si imposta LOCK_ESCALATION di una tabella?

Question

Stiamo riscontrando un problema con una replica di tipo merge. Il nostro editore esegue SQL Server 2008, mentre i nostri due abbonati eseguono il 2005. Il nostro editore sta cercando di inviare un comando ALTER TABLE Foo SET (LOCK_ESCALATION) ai nostri abbonati. Penso di ricordare di aver letto che questo comando è nuovo in SQL Server 2008 e, in tal caso, ha senso che il comando fallisca sui nostri server 2005. Tuttavia, la nostra replica di tipo merge è impostata per la compatibilità del 2005.

  

Lo script dello schema 'if object_id (N' [dbo]. [Users] ') non è null exec (' ALTER TABLE [dbo]. [Users] SET (LOCK_ESCALATION = TABLE)   ')' non può essere propagato al sottoscrittore.

Qualche idea sul perché il nostro editore dovrebbe provare a farlo?

Modifica: il livello di compatibilità del nostro server 2008 è impostato su " Sql Server 2005 (90) "

Answer 1

È una nuova funzionalità di sql 2008, quindi non supportata nel 2005. A seconda di quanto sia complessa la tua installazione, potresti prendere in considerazione la possibilità di eseguire il database con compatibilità 90 (sql 2005) per assicurarti di non aggiungere funzionalità di sql 2008 al tuo Banca dati. Ho avuto grossi problemi con la replica dei dati dello schema sin da quando è nato, quindi sempre un po 'reticente. Cerco sempre di renderlo stupido e di gestire semplicemente i dati: ho dovuto supportare un sistema di unione con 32 abbonati con replica di tipo merge e ho avuto costantemente grossi problemi di schema quando abbiamo spinto le modifiche dello schema.

Detto questo, se funziona come documentato, non dovrebbe tentare di forzare la modifica del blocco. Verificare che gli abbonamenti siano contrassegnati come sql 2005 compatibili. È probabile che non abbiano creato una mappa automatica delle impostazioni dal 2008 al 2005 come hanno fatto per i tipi di dati (ad esempio)

Uno dei ragazzi di sviluppo SQL bloggato sui nuovi tipi di blocco qualche tempo fa

Answer 2

Ciò si verifica perché l'incompatibilità di questa istruzione con sql server 2005 e, in modo analogo, quando eseguo una modifica dello schema in una tabella che si sta replicando, inserisce questa istruzione nelle modifiche dello schema.

Esistono due modi: rimuovere e creare nuovamente l'iscrizione, non applicabile quando si trova nel server di produzione. Il secondo modo è andare alla tabella sysmergeschemachange nel database ed eliminare la riga con qualcosa del genere:

  

Lo script dello schema 'if   object_id (N '[dbo]. [Users]') non lo è   null exec ('ALTER TABLE [dbo]. [Utenti]   SET (LOCK_ESCALATION = TABLE) ')'   non può essere propagato al file   abbonato.

Spero che questo aiuti.