March 2, 2015 at 12:05 am
Comments posted to this topic are about the item Are My Problems Caused By Replication?
March 2, 2015 at 12:16 am
You can also find out if a table is replicated by running the query below on the publisherSELECT * FROM sys.tables WHERE is_replicated = 1
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
March 2, 2015 at 12:34 am
Short answer No. It's how you are using replication and what you really shouldn't be doing with it ! If you must , the solution is a little easier than that. There are on each table replicated a set of triggers even the Tx replicated ones that prevent a range of changes. If you really need to use a dacpac then disable these triggers, script out these triggers as they are referenced within the replication structure, apply the dacpac replace the triggers and re-enable them. But using a dacpac on a replicated database is not usually a good idea. The thing about replication that make it all easier is to apply schema changes the publisher and let the replication agents take care of the database changes. There are several guidelines on technet on what you can and can't do, PK changes for a start. I'd also make sure you script out all the replication objects, because if the dacpac stamps all over your database then you will be rebuilding your replication from the start and on large production databases that will be a bit embarrassing.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply