Question

Consider this trigger:

ALTER TRIGGER myTrigger     ON someTable     AFTER INSERT AS BEGIN   DELETE FROM someTable          WHERE ISNUMERIC(someField) = 1 END 

I’ve got a table, someTable, and I’m trying to prevent people from inserting bad records. For the purpose of this question, a bad record has a field ‘someField’ that is all numeric.

Of course, the right way to do this is NOT with a trigger, but I don’t control the source code… just the SQL database. So I can’t really prevent the insertion of the bad row, but I can delete it right away, which is good enough for my needs.

The trigger works, with one problem… when it fires, it never seems to delete the just-inserted bad record… it deletes any OLD bad records, but it doesn’t delete the just-inserted bad record. So there’s often one bad record floating around that isn’t deleted until somebody else comes along and does another INSERT.

Is this a problem in my understanding of triggers? Are newly-inserted rows not yet committed while the trigger is running?

Answer 1

Triggers cannot modify the changed data (Inserted or Deleted) otherwise you could get infinite recursion as the changes invoked the trigger again. One option would be for the trigger to roll back the transaction.

Edit: The reason for this is that the standard for SQL is that inserted and deleted rows cannot be modified by the trigger. The underlying reason for is that the modifications could cause infinite recursion. In the general case, this evaluation could involve multiple triggers in a mutually recursive cascade. Having a system intelligently decide whether to allow such updates is computationally intractable, essentially a variation on the halting problem.

The accepted solution to this is not to permit the trigger to alter the changing data, although it can roll back the transaction.

create table Foo (        FooID int       ,SomeField varchar (10) ) go  create trigger FooInsert     on Foo after insert as     begin         delete inserted          where isnumeric (SomeField) = 1     end go   Msg 286, Level 16, State 1, Procedure FooInsert, Line 5 The logical tables INSERTED and DELETED cannot be updated. 

Something like this will roll back the transaction.

create table Foo (        FooID int       ,SomeField varchar (10) ) go  create trigger FooInsert     on Foo for insert as     if exists (        select 1          from inserted          where isnumeric (SomeField) = 1) begin               rollback transaction     end go  insert Foo values (1, '1')  Msg 3609, Level 16, State 1, Line 1 The transaction ended in the trigger. The batch has been aborted.