After insert trigger only using single inserted virtual table row 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.
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.