Question

There is a certain job that will insert and update this table called ContactInfo (with 2 columns – Id, EmailId) several times a day.

What’s a good way to write a trigger on this table to revert back the EmailId for only specific Ids, whenever only those EmailIds for those Ids get updated?

Don’t mind hard-coding those Ids in the trigger since the list is about 40.

But specifically concerned about trigger not firing for every update, since updates happen all the time, and don’t want the trigger to cause resource issues.

Additional info: table has about 600k entries and is indexed on Id.

In summary: is it possible for the trigger to get fired only when certain values are updated in the column, and not any update on the column.

Answer 1

One alternative mechanism you might consider would be adding another table, called, say, LockedValues. I’m a bit unsure from your narrative what values you’re trying to prevent changes to, but here’s an example:

Table T, contains two columns, ID and Val:

create table T (
    ID int not null,
    Val int not null,
    constraint PK_T PRIMARY KEY (ID),
    constraint UK_T_Lockable UNIQUE (ID,Val)
)

And we have 3 rows:

insert into T(ID,Val)
select 1,10 union all
select 2,20 union all
select 3,30

And we want to prevent the row with ID 2 from having it’s Val changed:

create table Locked_T (
    ID int not null,
    Val int not null,
    constraint UQ_Locked_T UNIQUE (ID,Val), --Only really need an index here
    constraint FK_Locked_T_T FOREIGN KEY (ID,Val) references T (ID,Val)
)
insert into Locked_T (ID,Val) select 2,20

And so now, of course, any application that is only aware of T will be unable to edit the row with ID 2, but can freely alter rows 1 and 3.

This has the benefit that the enforcement code is built into SQL Server already, so probably quite efficient. You don’t need a unique key on Locked_T, but it should be indexed so that it’s quite quick to detect that values aren’t present.

This all assumes that you were going to write a trigger that rejected changes, rather than one that reverted changes. For that, you’d still have to write a trigger (though I’d still suggest having this separate table, and then writing your trigger to do an update inner joining inserted with Locked_T – which should be quite efficient still).

(Be warned, however: Triggers that revert changes are evil)