Linq-to-sql failing on insert and update when this is a trigger attached

Question

I am having some problems with linq-to-sql lately. The problem is that it “thinks” that it fails on inserts and updates when we have a trigger attached to the event. An example could be a row, where a trigger is attached to set the “LastUpdated” colon to the current time, when a row is altered. This will cause linq-to-sql to think that is have failed on the update or insert, but this is only some times, as it sometimes go through, I think this is when the sql server is under heavy load and where therefore not able to execute the trigger before the validation was made, this is only speculation. As my scripts are only a part of a much bigger script, so disabling the trigger is not an option, so I need to find a solution to this, or rewrite my program. Have any of you experienced this problem and have found a solution, for example disabling validation after inserts?

The trigger.

USE [cnhha]
GO
/****** Object:  Trigger [dbo].[LastUpdated]    Script Date: 05/12/2011 16:26:51 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER TRIGGER [dbo].[LastUpdated] ON [dbo].[CN_User] 
FOR INSERT, UPDATE
AS

update cn_user set lastupdated=getdate() where campusnetuserid in (select campusnetuserid from inserted)

Answer 1

You probably need SET NOCOUNT ON in your trigger

Except the narrow case (SQLDataAdapter) mentioned in my question "SET NOCOUNT ON usage", it's required for most client code

You can remove the trigger too if you are able to change your client side UPDATE to use the DEFAULT keyword

update cn_user
set col1 = this, col2 = that,...,
    lastupdated= DEFAULT
where ...

Answer 2

Are your triggers returning any data through SELECT statements? See this MSDN article: CREATE TRIGGER

When a trigger fires, results are returned to the calling application, just as with stored procedures. To eliminate having results returned to an application due to a trigger firing, do not include either SELECT statements that return results, or statements that perform variable assignment in a trigger. A trigger that includes either SELECT statements that return results to the user or statements that perform variable assignment requires special handling; these returned results would have to be written into every application in which modifications to the trigger table are allowed. If variable assignment must occur in a trigger, use a SET NOCOUNT statement at the beginning of the trigger to eliminate the return of any result sets.

Also if you believe that the triggers are causing a heavy load on the database engine, have you considered using Service Broker to make their post-processing asynchronous?

If you could include the code for a representative trigger it would help us further diagnose the problem you're running into.