Annotations for "CHECKSUM (Transact-SQL)" topic.Fri, 09 Dec 2016 16:55:02 Zhttp://technet.microsoft.com/en-us/library/ms189788(v=sql.100).aspx#CommunityContent
Mike C_1Actually it is so bad...Although it is unfortunately not documented here as it should be, CHECKSUM is collation-sensitive. Try your example using different collations. Use the COLLATE clause to modify your sample code to test the effect of collations on your results.Sun, 15 May 2011 02:39:47 -0700http://technet.microsoft.com/en-us/library/ms189788(v=sql.100).aspx#CommunityContent
Yuri AbeleNot so bad ...This query did not find any equal CheckSums. I am shure what in some cases CheckSum will be the same, but not for combination between "AA" and "ZZ":DECLARE @C CHAR(1); SET @C = 'A';DECLARE @T TABLE(C CHAR(1));WHILE ASCII(@C) &lt;= ASCII('Z') BEGIN INSERT INTO @T VALUES(@C); SELECT @C = CHAR(ASCII(@C) + 1);END;SELECT CHK, [COUNT] = COUNT(*)FROM ( SELECT CC = T2.C + T1.C, CHK = CHECKSUM(T2.C + T1.C) FROM @T T1 CROSS JOIN @T TFri, 07 May 2010 15:50:53 -0700http://technet.microsoft.com/en-us/library/ms189788(v=sql.100).aspx#CommunityContent
Mike C_1"However, there is a small chance that the checksum will not change."CHECKSUM is *not* a collision-free hash function by any means. It generates 32-bit hash values, or checksums, which means collisions can be discovered by brute force with a complexity of 2^16 operations. However, the simple algorithm CHECKSUM uses appears to cycle after 16 bytes of data and collisions are frequent among data of the same length. For instance, "LE" and "AAAAAAAAAAAAAAAALE" both produce the same CHECKSUM value. Also "LE" and "MU" produce the same CHECKSUM value.In fact, among the 6Mon, 06 Apr 2009 05:44:02 -0700