Re: UNIQUE constraint problem
From: David Portas (REMOVE_BEFORE_REPLYING_dportas_at_acm.org)
Date: 06/14/04
- Next message: RP: "Re: sql2k: ole db timeout"
- Previous message: Denis Crotty: "data insertion"
- In reply to: Adam Machanic: "Re: UNIQUE constraint problem"
- Next in thread: Adam Machanic: "Re: UNIQUE constraint problem"
- Reply: Adam Machanic: "Re: UNIQUE constraint problem"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 14 Jun 2004 15:11:54 +0100
> Another mistake in the standard (and T-SQL, for being consistent).
Why
> should NULL = 0 effectively evaluate to true in a CHECK constraint but not
> anywhere else? Not only is that confusing to people who don't know it,
but
> it's also totally flawed from a logical point of view... That's like the
> database server saying, "It's probably 0. Good enough for me!"
[...]
> In terms of CHECK constraints, I have a philosophical problem with
them
> allowing NULLs due to the fact that I consider this inconsistent behavior.
It's not the case that NULLs are treated differently in CHECK constraints.
The ISO SQL definition of a CHECK constraint says:
"A table check constraint is satisfied if and only if the specified <search
condition> is not False for any row of a table."
Note the words "not False". In other words an error condition is only raised
when the constraint evaluates to FALSE, not if it evaluates to TRUE or
UNKNOWN. The expression is evaluated consistently in three-value logic but
the CHECK constraint allows the UNKNOWN case. This is again consistent with
the ANSI/ISO treatment of NULLs in a UNIQUE constraint (but not in
SQLServer).
-- David Portas SQL Server MVP --
- Next message: RP: "Re: sql2k: ole db timeout"
- Previous message: Denis Crotty: "data insertion"
- In reply to: Adam Machanic: "Re: UNIQUE constraint problem"
- Next in thread: Adam Machanic: "Re: UNIQUE constraint problem"
- Reply: Adam Machanic: "Re: UNIQUE constraint problem"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|