Systems Engineering and RDBMS

CHECKSUM Functions in SQL Server 2005

Posted by decipherinfosys on May 18, 2007

The key intent of the CHECKSUM functions is to build a hash index based on an expression or a column list. If say you use it to compute and store a column at the table level to denote the checksum over the columns that make a record unique in a table, then this can be helpful in determining whether a row has changed or not. This mechanism can then be used instead of joining with all the columns that make the record unique to see whether the record has been updated or not. SQL Server Books Online has a lot of examples on this piece of functionality.

A couple of things to watch out for when using these functions:

  1. You need to make sure that the column(s) or expression order is the same between the two checksums that are being compared else the value would be different and will lead to issues.
  2. We would not recommend using checksum(*) since the value that will get generated that way will be based on the column order of the table definition at run time which can easily change over a period of time. So, explicitly define the column listing.
  3. Be careful when you include the datetime data-type columns since the granularity is 1/300th of a second and even a small variation will result into a different checksum value. So, if you have to use a datetime data-type column, then make sure that you get the exact date + hour/min. i.e. the level of granularity that you want.

There are three checksum functions available to you:

  • CHECKSUM: This was described above.
  • CHECKSUM_AGG: This returns the checksum of the values in a group and Null values are ignored in this case. This also works with the new analytic function’s OVER clause in SQL Server 2005.
  • BINARY_CHECKSUM: As the name states, this returns the binary checksum value computed over a row or a list of expressions. The difference between CHECKSUM and BINARY_CHECKSUM is in the value generated for the string data-types. An example of such a difference is the values generated for “DECIPHER” and “decipher” will be different in the case of a BINARY_CHECKSUM but will be the same for the CHECKSUM function (assuming that we have a case insensitive installation of the instance). Another difference is in the comparison of expressions. BINARY_CHECKSUM() returns the same value if the elements of two expressions have the same type and byte representation. So, “2Volvo Director 20” and “3Volvo Director 30” will yield the same value, however the CHECKSUM() function evaluates the type as well as compares the two strings and if they are equal, then only the same value is returned. Example:
STRING              BINARY_CHECKSUM_USAGE    CHECKSUM_USAGE
------------------- ----------------------    -----------
2Volvo Director 20  -1356512636                -341465450
3Volvo Director 30  -1356512636                -341453853
4Volvo Director 40  -1356512636                -341455363

2 Responses to “CHECKSUM Functions in SQL Server 2005”

  1. […] One such option is the usage of triggers which upon an insert or an update, check for that set of columns and prevent the data entry from happening. I am not a big fan of this approach especially since in a high transaction system, it can create performance issues. Another method of enforcing such a constraint is by using a computed column and using the CHECKSUM() function. If you want to know the difference between the checksum functions, you can refer our previous blog post here. […]

  2. […] We have discussed the checksum functions before in our blog posts – you can access those posts here and here.  Yet another use of checksum functions is when you want to quickly compare two records […]

Sorry, the comment form is closed at this time.

 
%d bloggers like this: