validating publisher data against subscriber data

  • im running a test to see how to validate data on the publisher article vs the subscriber.

    Im running the below code:

    begin tran

    exec sp_marksubscriptionvalidation @publication = 'Customers',@subscriber = 'MYPC\instance2',@destination_DB = 'Subscriber_db'

    exec sp_article_validation @publication = 'Customers',@article = 'Customer',@rowcount_only = 0

    exec sp_article_validation @publication = 'Customers', @article = 'Customer',

    @rowcount_only = 0, @full_or_fast = 0, @shutdown_agent = 0,

    @subscription_level = 1

    commit

    I assumed the 1st proc call sets up validation on the subscriber. the 2nd call validates the data on the publisher and the 3rd returns the validation data(rowcount and a checksum).

    I updated data on the subscriber to ensure the rowcounts would differ from the publisher but when i run teh above code i get the same results for both calls of sp_article_validation:

    Generated expected rowcount value of 13 and expected checksum value of -10885695621 for Customer.

    Generated expected rowcount value of 13 and expected checksum value of -10885695621 for Customer.

    Can anyone tell me why the 2nd call is not returning different values, as the subscriber data is different? Do i have an incorrect understanding on how to validate publisher data vs subscriber data?

    EDIT: Pardon my ignorance. thought the results would show up in the query analyzer window, but just found out they show up in the replication monitor. issue is resolved!

  • The article name "Customer" is same in both statements.

    Example:

    exec sp_article_validation @publication = 'Pub_keys', @article = 'KeyToken', @rowcount_only = 0, @full_or_fast = 0, @shutdown_agent = 0, @subscription_level = 1

    exec sp_article_validation @publication = 'Pub_keys', @article = 'SymmetricKey', @rowcount_only = 0, @full_or_fast = 0, @shutdown_agent = 0, @subscription_level = 1

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply