# Be careful with constraints calling UDFs

You might just not get what you think. I would be surprised if this hasn’t been blogged already, but if so, it would be worth repeating. Here’s the deal (example from a forum,, slightly re-worked):

I want the values in one column to be unique, assuming the value in another column is 1. Can I use an UDF for that?

On the surface, yes. You can write an UDF to wich you pass the value which should be conditionally unique and in that UDF check how many rows has this value AND othercolumn = 1. If more than 1 row, then function returns 0, else 1 (or something else to signal “OK” or “Not OK”). Now, you can call this function in a CHECK constraint. Something like CHECK(myFunction(uniqueCol) = 1). this will on the surface do its job, as long as you INSERT into the table. But if you update a row and only set the otherColumn for some row from 0 to 1, then the check constraint will not be checked. The optimizer is smart enough to understand that the update doesn’t change anything that we refer to in our CHECK constraint, so why bother checking the constraint? End result here is that the constraint doesn’t do what we want it to do. Use a trigger instead (or some other method). Here’s a repro:

```USE tempdb GO IF OBJECT_ID('t') IS NOT NULL DROP TABLE t IF OBJECT_ID('t_uq') IS NOT NULL DROP FUNCTION t_uq GO```

``` CREATE TABLE t(c0 INT, c1 NVARCHAR(50), c2 bit) GO CREATE FUNCTION t_uq(@c1 NVARCHAR(50)) RETURNS bit AS BEGIN DECLARE @ret bit IF (SELECT COUNT(*) FROM t WHERE c1 = @c1 AND c2 = 1) > 1 SET @ret = 0 ELSE SET @ret = 1 RETURN @ret END GO ALTER TABLE t ADD CONSTRAINT t_c CHECK(dbo.t_uq(c1) = 1) INSERT INTO t(c0, c1, c2) VALUES(1, 'a', 0) --OK INSERT INTO t(c0, c1, c2) VALUES(2, 'a', 0) --OK INSERT INTO t(c0, c1, c2) VALUES(3, 'b', 1) --OK INSERT INTO t(c0, c1, c2) VALUES(4, 'b', 1) --Fails --So far so good, but watch now: UPDATE t SET c2 = 1 WHERE c0 = 2 --No error, the constraint doesn't do its job! ```

```--We have invalid data: SELECT * FROM t```