HASHBYTES giving different resaults than yesterday

  • OKI, here is what happened but we dont understand why. the query that was running until yesterday it is not running anymore.

    we try changing the data type to nvarchar and only 1/2 of the records match.

    i think the data type is going crazy on my server, not sure why.

  • astrid 69000 wrote:

    I tried, but we are still having records that are unmatched.

    Then you have actually having records that don't match because the function is not capable of creating different outputs for the same input.  You need to check further.  For example, did someone add a column to what is being hashed quite by accident by doing something like adding snapshot isolation, which adds 14 byte column to the data?

    Look around.  Something certainly changed but it will not be the hashbyte function that is the problem.  It will be the data you are feeding it and you've simply not yet determined what it is.

    --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 2 posts - 16 through 16 (of 16 total)

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