I must be loosing my mind. Odd data issue

  • I have a guest table on two servers. Call them prod1 and prod2. The Prod1 database is backed up and restored to the prod2 server everyday. The backup starts around 11 pm and the restore the prod2 finishes around 10:30 am

    --this is to check what records exist on prod1 that dont exist on prod2

    select o.Id

    , o.CreatedDate

    , o.LastModifiedDate

    --, *

    from [prod1].[xxx].[dbo].

    o   --old

    left join [prod2].[xxx].[dbo].guest n --new...this is using a linked server connection

    on n.Id = o.Id

    where n.Id is null


    This returns records with a create data of several days ago. The data on prod1 is refreshed using dbamp from salesforce cloud every 10 mins. It pulls the records changed in the last 30 mins then does a delete and insert not wrapped in a transaction. When I check to see if the records returned exist on prod2, they do. The amount of records changes every time I run it as well. I should only see records being returned that were created when the backup started. Long and short, it is saying the records dont exist on prod2 then when i check prod2 they do indeed exists. Am i going crazy?

    • This topic was modified 1 year, 2 months ago by  Snargables.
  • Not sure, but with data, often it's something small I've missed.

    Rather than this join, what I'd pick is a row or two that I  am struggling with and limit my investigation to those. Check the row on prod1, then on prod2 separately, then limit this query to those to see if I might have something strange in the logic.

    Off the top of my head, this should find those rows, but data conflicts sometimes are strange.

  • Keep it simple...

    --===== Find all items in Prod1 that are not in Prod2
    SELECT * FROM prod1.xxx.dbo.guest
    SELECT * FROM prod2.xxx.dbo.guest
    --===== Find all items in Prod2 that are not in Prod1
    SELECT * FROM prod2.xxx.dbo.guest
    SELECT * FROM prod1.xxx.dbo.guest

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

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

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