You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Specifies that the computation covers all the table columns. BINARY_CHECKSUM ignores columns of noncomparable data types in its computation. Noncomparable data types include
39
-
***cursor**
40
-
***image**
41
-
***ntext**
42
-
***text**
43
-
***xml**
44
-
45
-
and noncomparable common language runtime (CLR) user-defined types.
46
-
47
-
*expression*
48
-
An [expression](../../t-sql/language-elements/expressions-transact-sql.md) of any type. BINARY_CHECKSUM ignores expressions of noncomparable data types in its computation.
49
-
50
-
## Return Types
51
-
**int**
52
-
53
-
## Remarks
54
-
`BINARY_CHECKSUM(*)`, computed on any row of a table, returns the same value as long the row isn't modified later. `BINARY_CHECKSUM` satisfies the properties of a hash function: when applied over any two lists of expressions, returns the same value if the corresponding elements of the two lists have the same type and are equal when compared using the equals (=) operator. For this definition, we say that null values, of a specified type, compare as equal values. If at least one of the values in the expression list changes, the expression checksum can also change. However, this change isn't guaranteed, and so to detect whether values have changed, we recommend use of `BINARY_CHECKSUM` only if your application can tolerate an occasional missed change. Otherwise, consider using `HASHBYTES` instead. With a specified MD5 hash algorithm, the probability that `HASHBYTES` will return the same result, for two different inputs, is much lower than `BINARY_CHECKSUM`.
55
-
39
+
40
+
#### _*_
41
+
42
+
Specifies that the computation covers all the table columns. `BINARY_CHECKSUM` ignores columns of noncomparable data types in its computation. Noncomparable data types include:
43
+
44
+
-**cursor**
45
+
-**image**
46
+
-**ntext**
47
+
-**text**
48
+
-**xml**
49
+
- noncomparable common language runtime (CLR) user-defined types
50
+
51
+
#### _expression_
52
+
53
+
An [expression](../language-elements/expressions-transact-sql.md) of any type. `BINARY_CHECKSUM` ignores expressions of noncomparable data types in its computation.
54
+
55
+
## Return types
56
+
57
+
**int**
58
+
59
+
## Remarks
60
+
61
+
`BINARY_CHECKSUM(*)`, computed on any row of a table, returns the same value as long the row isn't modified later. `BINARY_CHECKSUM` satisfies the properties of a hash function: when applied over any two lists of expressions, it returns the same value if the corresponding elements of the two lists have the same type and are equal when compared using the equals (`=`) operator.
62
+
63
+
For this definition, we say that null values, of a specified type, compare as equal values. If at least one of the values in the expression list changes, the expression checksum can also change. However, this change isn't guaranteed, and so to detect whether values have changed, you should use `BINARY_CHECKSUM` only if your application can tolerate an occasional missed change. Otherwise, consider using `HASHBYTES` instead. With a specified MD5 hash algorithm, the probability that `HASHBYTES` returns the same result, for two different inputs, is much lower than `BINARY_CHECKSUM`.
64
+
56
65
`BINARY_CHECKSUM` can operate over a list of expressions, and it returns the same value for a specified list. `BINARY_CHECKSUM` applied over any two lists of expressions returns the same value if the corresponding elements of the two lists have the same type and byte representation. For this definition, null values of a specified type are considered to have the same byte representation.
57
-
66
+
58
67
`BINARY_CHECKSUM` and `CHECKSUM` are similar functions. They can be used to compute a checksum value on a list of expressions, and the order of expressions affects the resultant value. The order of columns used for `BINARY_CHECKSUM(*)` is the order of columns specified in the table or view definition. This ordering includes computed columns.
59
-
60
-
`BINARY_CHECKSUM` and `CHECKSUM` return different values for the string data types, where locale can cause strings with different representation to compare as equal. The string data types are
61
-
62
-
***char**
63
-
***nchar**
64
-
***nvarchar**
65
-
***varchar**
66
-
67
-
or
68
-
69
-
***sql_variant** (if the base type of **sql_variant** is a string data type).
70
-
71
-
For example, the strings "McCavity" and "Mccavity" have different `BINARY_CHECKSUM` values. In contrast, for a case-insensitive server, `CHECKSUM` returns the same checksum values for those strings. You should avoid comparison of `CHECKSUM` values with `BINARY_CHECKSUM` values.
72
-
73
-
`BINARY_CHECKSUM` supports any length of type **varbinary(max)** and up to 255 characters of type **nvarchar(n | max)**.
74
-
75
-
## Examples
68
+
69
+
`BINARY_CHECKSUM` and `CHECKSUM` return different values for the string data types, where locale can cause strings with different representation to compare as equal. The string data types are:
70
+
71
+
-**char**
72
+
-**nchar**
73
+
-**nvarchar**
74
+
-**varchar**
75
+
-**sql_variant** (if the base type of **sql_variant** is a string data type)
76
+
77
+
For example, the strings `McCavity` and `Mccavity` have different `BINARY_CHECKSUM` values. In contrast, for a case-insensitive server, `CHECKSUM` returns the same checksum values for those strings. You should avoid comparison of `CHECKSUM` values with `BINARY_CHECKSUM` values.
78
+
79
+
`BINARY_CHECKSUM` supports any length of type **varbinary(max)**, and up to 255 characters of type **nvarchar(_n_)** / **nvarchar(max)**.
80
+
81
+
## Examples
82
+
76
83
This example uses `BINARY_CHECKSUM` to detect changes in a table row.
0 commit comments