September 18, 2005 at 3:35 am
I've been thinking:
maybe I can do something with the sp_msenumchanges stored procedure to see if my databases are in sync.
September 21, 2005 at 2:57 am
Hi,
If you are unsure of using the specific sp's then it is quite reasonable to drop the merge replication to apply any database changes and then re-apply. Of course, in order to save you the pain of pushing out a new subscription it is a good idea to synchronise the data before dropping the replication. I am making the assumption that you have specific users that are configured to make changes to the database..if this is so then put the databases into DBO Use Only , and then run the merge agent a few times to synch the data. Once done you can drop the rep.
One thing to look out for when you re-apply the replication is the identity ranges and current identity values.
HTH...Graeme
September 22, 2005 at 12:08 pm
Hi, thx for the reply.
I'm not using identity columns, so this will not be a problem. My primary key's are GUID's (which are also the rowcolguid).
About putting the DB in 'restricted user mode': I've been thinking on this as well. This is something I surely have to do.
But, why should I run the merge agent a couple of times ? Isn't it enough to run it once ?
September 23, 2005 at 1:44 am
Well, all you are really trying to do is make sure the data is the same both ends of the replication. You can always do a row count to check the synch. I have just found that runnung the agent two or three times will make sure the backlog of transactions are cleared. 99 times out of 100 this is probably not necessary..but..you never know.
You don't have to put the DBs into DBO Use only to drop and reapply merge rep. It's more of a safe guard against non dbo users attempting to add data to the DBs while the replication is off.
HTH Graeme
Viewing 4 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply