What am I doing wrong with this SQL Server 2012 trigger? - sql

Question

I can't get what should be a simple trigger to work.
It fires after INSERT, tests whether Column A is null, and if so sets it to the value of Column B on that same row.
After the insert, I check the inserted row, and Column B has a value, but Column A is null.
The trigger is enabled and is being fired, because in despair I was logging values to a work table at various points,
and these values are what is expected.
I even tried to do a temporary bypass of this issue by going into Design on this table and specifying a "Default Value" of 1000 for this column, but it still comes out null.
And I tried changing the trigger to set Column A to a fixed value of 987, but it still comes out null.
Is there some idiosyncrasy about inserts that I don't know about? Any advice is appreciated.
BACKGROUND -----------------------------------------------------------------------------
OPTIONS is a table which stores "Options" which an attendee at one of our events can register for (e.g., a ticket to the event, an optional steak or chicken dinner, etc.)
These Options are inserted when the event is being defined (dates, venues, contact info, and the options which attendees can register for).
The Options table:
OptionID INT (Identity, primary key)
...
MaxAttendees INT
...
AvlbRemainingRegQty INT
That last column is the column not getting set - it's supposed to be a running total of how many chicken dinners are remaining to be sold
I thought I was going crazy and/or doing something stupid, so I created a zTestTrigger table to store the values from the INSERTED row and to verify that the trigger got to certain points.
WhichPartOfTest VARCHAR(100)
OptionID INT
AvlbRemRegQty INT
MaxAttendees INT
--DETAILS ---------------------------------------------------
USE [dbname]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER TRIGGER [dbo].[trig_Options_AvlbRemainingRegQty]
ON [dbo].[Options]
AFTER INSERT
AS
SET NOCOUNT ON
DECLARE #I_OptionID INT
DECLARE #I_AvlbRemainingRegQty INT
DECLARE #I_MaxAttendees INT
SELECT
#I_OptionID = I.OptionID,
#I_AvlbRemainingRegQty = ISNULL(I.AvlbRemainingRegQty,-1),
#I_MaxAttendees = MaxAttendees
FROM Inserted I
insert into zTestTrigger values ('Start of new test - values from INSERTED row are:',#I_OptionID, #I_AvlbRemainingRegQty, #I_MaxAttendees)
IF ISNULL(#I_AvlbRemainingRegQty,-1) = -1 --(I had also tried checking IF I_AvlbRemainingRegQty IS NULL)
begin
insert into zTestTrigger values ('About to update table, setting AvlbRemQty = ' + cast(#I_MaxAttendees as varchar) + ' where id = ' + cast(#I_OptionID as varchar),
#I_OptionID, #I_AvlbRemainingRegQty, #I_MaxAttendees)
UPDATE Options SET AvlbRemainingRegQty = #I_MaxAttendees WHERE OptionID = #I_OptionID
--Originally, I tried this:
--UPDATE OPTIONS SET AvlbRemainingRegQty = ISNULL(MaxAttendees,1000) WHERE OptionID = #I_OptionID
--This doesn't work either:
--UPDATE OPTIONS SET SET AvlbRemainingRegQty = SELECT ISNULL(MaxAttendees,1000) FROM Options WHERE OptionID = #I_OptionID) WHERE OptionID = #I_OptionID
--I even tried:
--UPDATE OPTIONS SET AvlbRemainingRegQty = 987 WHERE OptionID = #I_OptionID
declare #error int
set #error = ##ERROR
insert into zTestTrigger values ('##ERROR is ' + cast(#error as varchar), 0,0,0) --Shows that #Error is 0
end
Selecting from the zTestTrigger table shows
"About to update table, setting AvlbRemQty = 1000 where id = 491" , 491, -1, and 1000
and I can select the row with ID 491, but its Avlb Rem Qty is null.

Answer 1

I would personally use an instead of trigger for this, since it allows us to put the data in correctly, right from the start.
But for now, we'll do the after trigger:
ALTER TRIGGER [dbo].[trig_Options_AvlbRemainingRegQty]
ON [dbo].[Options]
AFTER INSERT
AS
SET NOCOUNT ON
UPDATE Options
SET
AvlbRemainingRegQty = COALESCE(AvlbRemainingRegQty, MaxAttendees)
WHERE
OptionID in (select OptionID from inserted)
And note that this trigger (unlike yours) recognizes that inserted can contain 0, 1 or multiple rows. So treat it as a table, not as something from which separate, scalar variables can have meaningful values assigned.
Just as another point though:
it's supposed to be a running total of how many chicken dinners are remaining to be sold
In general, this is a bad idea. If you are storing details of each sale separately, the number remaining is a value that can be calculated. All that you do be storing such a value is give yourself an opportunity for the stored value to be inconsistent with the rest of your data.