Jeff Moden (8/9/2009)

---

Even then, it can and will give an incorrect answer if you rely only on it. I'll admit that CHECKSUM will help narrow things down on long strings, though.

Jeff Moden (8/10/2009)

---

Ummmm.... does SQL Server's CHECKSUM use the SHA1 algorithm because I was talking about that CHECKSUM. Obviously that doesn't take 6000 to 12000 years to happen because I've seen two of these same types of posts in the last 3 months.

RBarryYoung (8/10/2009)

---

To clarify: HashBytes w/ SHA1 is nigh-unbreakable.

Paul White (8/10/2009)

---

Hey Barry,

On the other hand, it is relatively slow, only works on strings, and returns varbinary(8000).
If the task is to detect changes in a row of data, would you use HashBytes (SHA1) alone?

Paul

Jeff Moden (8/10/2009)

---

In Lowell's example, it also turned a 13 byte string into a 20 byte Varbinary so it's expensive, too. But, I believe that Barry's point was simply that it is unbreakable... not like CHECKSUM at all.

Paul White (8/10/2009)

---

Hey Barry,

On the other hand, it is relatively slow, only works on strings, and returns varbinary(8000).
If the task is to detect changes in a row of data, would you use HashBytes (SHA1) alone?

Paul

Paul White (8/10/2009)

---

So...SHA1 always returns 160 bits (20 bytes) regardless of the input. HashBytes also appears to be limited to 8000 bytes of input - 8000 ANSI characters or 4000 Unicode. Finally, it doesn't appear unbreakable either: Wikipedia Link.

I mentioned HashBytes way back - now I'm just pointing out some of the reasons that I have yet to use it in a real production system.

Paul