Are SQL Server unique constraints "Silent" or do they raise an exception? - sql

Question

I want to prevent inserting duplicate values into my tables. At first, I added code to check if the value already existed in the database, but that seems like a lot of overhead / wasted time if I can prevent it at the DDL level.
So I found this and changed one of my tables (as an example) from this:
CREATE TABLE [dbo].[ACTORS]
(
[Id] INT IDENTITY (1, 1) NOT NULL,
[ActorId] CHAR(9) NOT NULL,
[Actor] VARCHAR(50) NOT NULL,
PRIMARY KEY CLUSTERED ([Id] ASC),
);
to this:
CREATE TABLE [dbo].[ACTORS]
(
[Id] INT IDENTITY (1, 1) NOT NULL,
[ActorId] CHAR(9) NOT NULL,
[Actor] VARCHAR(50) NOT NULL,
PRIMARY KEY CLUSTERED ([Id] ASC),
CONSTRAINT [CK_ACTORS_Column]
UNIQUE NONCLUSTERED ([ActorId] ASC)
);
I want the constraint to prevent a second identical ActorId without whin[g]ing about it. IOW, just bypass it, don't tell me about it, don't stop the app or throw an exception.
Is this how it works (silently), or will it throw an exception?

Answer 1

#GMB wrote in his answer "SQL Server has built-in no option (that I know about) to ignore such error".
As #a_horse_with_no_name pointed out in the comment, there is an IGNORE_DUP_KEY option of an index that is relevant here.
You said:
I want the constraint to prevent a second identical ActorId without
whin[g]ing about it. IOW, just bypass it, don't tell me about it,
don't stop the app or throw an exception.
It can be achieved with this option.
At first, I should point out that when you create a unique constraint
CONSTRAINT [CK_ACTORS_Column] UNIQUE NONCLUSTERED ([ActorId] ASC)
the engine will create a unique index to enforce the constraint. The constraint is a logical concept, the index is a physical implementation of the concept.
You can achieve the same effect by creating just an index, a unique index. When you create an index you can specify various options, including the IGNORE_DUP_KEY option.
IGNORE_DUP_KEY = { ON | OFF }
Specifies the error response when an
insert operation attempts to insert duplicate key values into a unique
index. The IGNORE_DUP_KEY option applies only to insert operations
after the index is created or rebuilt. The option has no effect when
executing CREATE INDEX, ALTER INDEX, or UPDATE. The default is OFF.
ON A warning message will occur when duplicate key values are inserted
into a unique index. Only the rows violating the uniqueness constraint
will fail.
OFF An error message will occur when duplicate key values are inserted
into a unique index. The entire INSERT operation will be rolled back.
By default this option is OFF, so an attempt to insert a duplicate key value will fail with an error. The server will roll back the INSERT operation and send this error message to your application and it will depend on your application how to handle it. If your application doesn't expect it, it will likely throw some exception.
If you set this option to ON, your application will no longer receive an error message. It will receive a warning message, which most applications usually ignore. So, it will look like the server silently ignores duplicate values and inserts only those values that are not duplicates.
It is rarely a desired behaviour to silently ignore problems, but if you really know what you are doing, you can do it.
Here is a short demo.
Let's start with your table
CREATE TABLE [dbo].[ACTORS]
(
[Id] INT IDENTITY (1, 1) NOT NULL,
[ActorId] CHAR(9) NOT NULL,
[Actor] VARCHAR(50) NOT NULL,
PRIMARY KEY CLUSTERED ([Id] ASC),
);
Option 1. Default. IGNORE_DUP_KEY = OFF
CREATE UNIQUE NONCLUSTERED INDEX [IX_ActorID] ON [dbo].[ACTORS]
(
[ActorId] ASC
) WITH (IGNORE_DUP_KEY = OFF)
The table is empty. Let's try to insert some values.
insert into actors (actorid, actor) values('foo', 'bar');
-- (1 row affected)
Let's try to insert a duplicate value:
insert into actors (actorid, actor) values('foo', 'baz');
--Msg 2601, Level 14, State 1, Line 4
--Cannot insert duplicate key row in object 'dbo.ACTORS' with unique index 'IX_ActorID'.
--The duplicate key value is (foo ).
--The statement has been terminated.
Let's try to insert several values in a single statement with some duplicates:
insert into actors (actorid, actor) values
('foo', 'baz'),
('fo2', 'baz'),
('fo2', 'baz'),
('fo3', 'baz'),
('fo3', 'baz'),
('fo3', 'baz'),
('fo4', 'baz');
--Msg 2601, Level 14, State 1, Line 16
--Cannot insert duplicate key row in object 'dbo.ACTORS' with unique index 'IX_ActorID'.
--The duplicate key value is (foo ).
--The statement has been terminated.
Let's see what we have in the table now.
SELECT * FROM Actors;
+----+-----------+-------+
| Id | ActorId | Actor |
+----+-----------+-------+
| 1 | foo | bar |
+----+-----------+-------+
Only the first INSERT statement succeeded and only one row was inserted.
Now, clean up.
DROP INDEX [IX_ActorID] ON [dbo].[ACTORS];
TRUNCATE TABLE dbo.Actors;
Option 2. IGNORE_DUP_KEY = ON
CREATE UNIQUE NONCLUSTERED INDEX [IX_ActorID] ON [dbo].[ACTORS]
(
[ActorId] ASC
) WITH (IGNORE_DUP_KEY = ON)
The table is empty. Let's try to insert some values.
insert into actors (actorid, actor) values('foo', 'bar');
-- (1 row affected)
Let's try to insert a duplicate value:
insert into actors (actorid, actor) values('foo', 'baz');
--Duplicate key was ignored.
--(0 rows affected)
As you can see, now it is not an error message. It is just a warning "Duplicate key was ignored."
Let's try to insert several values in a single statement with some duplicates:
insert into actors (actorid, actor) values
('foo', 'baz1'),
('fo2', 'baz2'),
('fo2', 'baz3'),
('fo3', 'baz4'),
('fo3', 'baz5'),
('fo3', 'baz6'),
('fo4', 'baz7');
--Duplicate key was ignored.
--(3 rows affected)
Here you can see that out of 7 rows only 3 rows were inserted.
Let's see what we have in the table now.
SELECT * FROM Actors;
+----+-----------+-------+
| Id | ActorId | Actor |
+----+-----------+-------+
| 1 | foo | bar |
| 4 | fo2 | baz2 |
| 6 | fo3 | baz4 |
| 9 | fo4 | baz7 |
+----+-----------+-------+
You can see that the last INSERT statement inserted non-duplicate values. Also, have a close look at the values in ID column. The IDENTITY values have gaps, because they were generated for each row that was attempted to be inserted and some of these rows were rejected by the unique index.
Overall, this index option is designed primarily for the cases when you need to insert a lot of rows in bulk, in a single INSERT statement, but you expect that some of these row may violate the unique constraint. You don't want the whole large INSERT statement to fail, you want only few violating rows to be ignored. Without this option you would have to try to insert your values one-by-one, row-by-row, which may be much slower than a single INSERT statement.

Answer 2

Let's try that:
insert into actors (actorid,actor) values('foo', 'bar');
-- 1 row affected
insert into actors (actorid, actor) values('foo', 'baz');
-- Msg 2627 Level 14 State 1 Line 1
-- Violation of UNIQUE KEY constraint 'CK_ACTORS_Column'.
-- Cannot insert duplicate key in object 'dbo.ACTORS'. The duplicate key value is (foo ).
A unique constraint violation does raise an error. This is how the database lets you know that something went wrong.
SQL Server has built-in no option (that I know about) to ignore such error, unlike many other databases (MySQL, Postgres, SQLite...). A workaround is to rewrite the insert with not exists and a subquery:
insert into actors (actorid, actor)
select v.*
from (values ('foo', 'bar')) v(actorid, actor)
where not exists (select 1 from actor a where a.actorid = v.actorid)
Another option is the merge statement:
merge into actors a
using (values ('foo', 'bar')) v(actorid, actor)
on v.actorid = a.actorid
when not matched then insert (actorid, actor)
values (v.actorid, v.actor)