Transactional Replication with difference in tables...

  • 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!

  • No one knows what could be wrong?

  • 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?



    Colleen M. Morrow
    Cleveland DBA

  • Can you also tell if replicated tables in Server A is having more rows than Server B or vice versa?

    M&M

  • There was 1 table missing 1 row.. 🙁

  • - 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