June 23, 2011 at 5:39 am
We are replicating (transactional) a db with only 2 tables for a migration (from production server A to future production server B).
With Replication Monitor, everything seems fine (ok) and running, no undistributed commands...
But when I check both tables with SQL TableDiff, I'm getting differences in the tables.
Yesterday, we didn't had differences, just today (while monitoring says it's all ok)...
Ok, TableDiff generates a query to update the tables on server B, but...
How is this possible?
only reason I can imagine is server A is SQL Server 2005 and server B SQL Server 2008R2.
But normaly this cann't be the reason!
June 28, 2011 at 5:16 am
No one knows what could be wrong?
June 28, 2011 at 9:39 am
From BOL:
Data at the Publisher and Subscriber can be non-convergent for a number of reasons:
* Data is updated at a Subscriber that should be treated as read-only. The subscription database should be treated as read-only unless you are using merge replication, transactional replication with updatable subscriptions, or peer-to-peer transactional replication.
* Triggers are used at the Subscriber. Triggers can modify data at the Subscriber and also prevent the data from being updated if the trigger issues a ROLLBACK.
* Scripts are executed by replication at the Subscriber but not at the Publisher.
* Replication of stored procedure execution for a transactional publication produces different results at the Subscriber.
* Constraint violations or other issues prevent rows from being inserted, updated, or deleted at the Subscriber.
Do any of these apply to your situation?
June 28, 2011 at 10:53 am
Can you also tell if replicated tables in Server A is having more rows than Server B or vice versa?
M&M
June 30, 2011 at 7:39 am
There was 1 table missing 1 row.. 🙁
June 30, 2011 at 7:42 am
- nothing changed it the subscriber, it's only online to test the connections
- no triggers
But it's possible the last reason, gonna check the update queries... thx
Colleen M. Morrow (6/28/2011)
From BOL:Data at the Publisher and Subscriber can be non-convergent for a number of reasons:
* Data is updated at a Subscriber that should be treated as read-only. The subscription database should be treated as read-only unless you are using merge replication, transactional replication with updatable subscriptions, or peer-to-peer transactional replication.
* Triggers are used at the Subscriber. Triggers can modify data at the Subscriber and also prevent the data from being updated if the trigger issues a ROLLBACK.
* Scripts are executed by replication at the Subscriber but not at the Publisher.
* Replication of stored procedure execution for a transactional publication produces different results at the Subscriber.
* Constraint violations or other issues prevent rows from being inserted, updated, or deleted at the Subscriber.
Do any of these apply to your situation?
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply