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)
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 ...
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.
You can take the help from SQL profiler for all the activities happening during the process.You can capture and save data about each event to a file or table.
If having the trigger update the property value behind your code's back is messing with your custom entity validation logic, can you either avoid the trigger altogether and directly set the LastUpdated
property on the entity, or not perform any validation (other than schema validation) on the value of the LastUpdated
property?