# Sql-server – After insert trigger only using single inserted virtual table row

sql serversql-server-2008-r2trigger

I have a trigger that updates multiple columns in a table for rows inserted into another table.

A record inserted into the fuelTransactionInfo column, updates a column in fuelTransactions, based on the "info code", finding the correct row using fuelTransactionId. I'm just denormalizing some data for easier reporting.

The rows can be inserted into the fuelTransactionInfo column with multiple values. E.g.,

INSERT INTO fuelTransactionInfo
(...cols)
VALUES
(...values),
(...values),
(...values);


My issue is that only the first set of values is being used in the trigger. I understand that triggers are fired on the statement, not the rows, and I believe the trigger code accounts for that. However, it's simply not working.

Here is my trigger code:

ALTER TRIGGER [dbo].[fuelTransactionInfoDev_DenormalizeFuelTransactions]
ON  [ERPDev].[dbo].[fuelTransactionInfo]
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON

UPDATE t SET
t.employeeNumber = CASE
WHEN fuelInfoCodes.efsCode = 'DRID' THEN
inserted.value
ELSE t.employeeNumber
END,
t.unitNumber = CASE
WHEN fuelInfoCodes.efsCode = 'UNIT' THEN
inserted.value
ELSE t.unitNumber
END,
t.contractId = CASE
WHEN fuelInfoCodes.efsCode = 'CNTN' THEN
(SELECT c.id
FROM pinContract p
JOIN contracts c
ON c.contractNumber = p.ContractNumber
WHERE pin = inserted.value)
ELSE t.contractId
END,
t.contract = CASE
WHEN fuelInfoCodes.efsCode = 'CNTN' THEN
(SELECT c.contractNumber
FROM pinContract p
JOIN contracts c
ON c.contractNumber = p.ContractNumber
WHERE pin = inserted.value)
ELSE t.contract
END,
t.driverName = CASE
WHEN fuelInfoCodes.efsCode = 'NAME' THEN
inserted.value
ELSE t.driverName
END,
t.subFleet = CASE
WHEN fuelInfoCodes.efsCode = 'SSUB' THEN
inserted.value
ELSE t.subFleet
END
FROM fuelTransactions t
JOIN inserted
ON inserted.fuelTransactionid = t.id
JOIN fuelInfoCodes
ON fuelInfoCodes.id = inserted.fuelInfoCodeId;
END


I've done a little bit of testing by adding the following statement to the trigger:

SELECT * FROM INSERTED INTO insertedTest


I see all the expected rows in the insertedTest table. I've tested the UPDATE statement by converting it into an equivalent select (based on the insertedTest table, instead of "inserted"), and all the joins are good.

Only the column in the 'UNIT' case is actually updated in fuelTransactions, which happens to be the first row in every single insert firing the trigger.

What am I doing wrong? Let me know if you need more info.

#### Best Answer

The reason it's not working is that your join causes each row to be updated multiple times, but each update sees only the original values, not the cumulative values of previous updates. So your updates are in effect cancelling the previous updates. (Or maybe SQL only allows one row update per statement. Either way the result is the same, with different resource use.)

Here's a quick and poorly formatted repro:

declare @insertedexample table (id INT, codeid int, value varchar(10))

INSERT INTO @insertedexample VALUES
(1,1,'newvalue1'),
(1,2,'newvalue2')

declare @targetexample table (id INT, codeid1value varchar(10), codeid2value varchar(10))

INSERT INTO @targetexample VALUES
(1, 'origvalue1', 'origvalue2')

SELECT * FROM @targetexample

UPDATE t
SET
t.codeid1value = CASE WHEN i.codeid=1 THEN i.value ELSE t.codeid1value END,
t.codeid2value = CASE WHEN i.codeid=2 THEN i.value ELSE t.codeid2value END
FROM @targetexample t
JOIN @insertedexample i on i.id = t.id

SELECT * FROM @targetexample


The only way I can think of at the moment to handle this is by building a dynamic query.

Aaron's suggestion of a view would certainly be better, provided users will only be filtering by fuelTransactions.id or the data will remain small enough to handle filtering after pivoting. (Edit: I later realised that it might also be possible to create a view, or a set of views, or certainly a function, that would allow efficient additional filtering, dependent of course on supporting indexing in the base table.)

UPDATE:

Actually you probably don't need a dynamic query, since the columns in the fuelTransactions table are fixed as are the efsCode codes you're interested in.

You might be able to use a pivot of one form or another, which incorporates the current values for the columns not being updated, even if you have to use a bunch of ugly subqueries.
I might have time to experiment with it, but can't promise.