Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Using Triggers for Detective Work Expand / Collapse
Author
Message
Posted Thursday, July 17, 2008 7:25 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Sunday, August 3, 2014 3:41 PM
Points: 1,219, Visits: 1,430
Comments posted to this topic are about the item Using Triggers for Detective Work
Post #536410
Posted Thursday, September 25, 2008 2:35 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, May 5, 2011 1:38 AM
Points: 1,636, Visits: 604
Hello Tom,
it may have worked in your particular environment, but I don't think it is a good idea to post this trigger in an article... unless it is an article "What to avoid when writing triggers".

Even at first glance, this trigger has a major problem, because it only works if ONE row is updated. What happens if you update 10 or 500 rows at once? Even if your applications always update one row, any triggers should be written so that they can handle any amount of rows in one update. You can never know what will happen in some future version of some of the applications, and of course there can be some "extra" access (like update issued from QA by DBA). Also, you are doing 2 inserts in the trigger, while the same can be accomplished with one.

IMHO, it would be better to write the check this way:

CREATE TABLE [dbo].[Tmp_LogRangeRanges](
-- Copy of the original table, where a column was being truncated, with columns for new and old value
[pKey] [bigint],
[$timeStamp_old] [datetime] NULL,
[fRange_old] [bigint] NULL,
[region_old] [varchar](32) NULL,
[startLoc_old] [int] NULL,
[endLoc_old] [int] NULL,
[project_old] [varchar](300) NULL,
[$timeStamp_new] [datetime] NULL,
[fRange_new] [bigint] NULL,
[region_new] [varchar](32) NULL,
[startLoc_new] [int] NULL,
[endLoc_new] [int] NULL,
[project_new] [varchar](300) NULL,
-- Additional columns for identifying what caused the error
[ChangeDate] datetime Default GetDate(),
[Machine] sysname,
[User] sysname,
[APP] sysname )

CREATE TRIGGER u_LogRangeRanges ON dbo.RangeRanges FOR UPDATE
AS
BEGIN
INSERT INTO Tmp_LogRangeRanges
(pKey, [$timestamp_old], fRange_old, region_old, startLoc_old, endLoc_old, project_old
[$timestamp_new], fRange_new, region_new, startLoc_new, endLoc_new, project_new,
Machine, [User], APP)
SELECT i.pKey, d.[$timestamp], d.fRange, d.region, d.startLoc, d.endLoc, d.project,
i.[$timestamp], i.fRange, i.region, i.startLoc, i.endLoc, i.project,
HOST_NAME(), SUSER_SNAME(), APP_NAME()
FROM DELETED d
JOIN INSERTED i ON i.pKey=d.pKey
WHERE d.Region <> i.Region
END
GO

It is quite probable that others will come up with even better solution, I was just trying to do minimum changes in your code to achieve reliable result. I hope I didn't mistype something, the code is not tested.



Post #575776
Posted Thursday, November 27, 2008 1:42 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Sunday, August 3, 2014 3:41 PM
Points: 1,219, Visits: 1,430
Hi Vladen,

You're right its not an ideal way to write a trigger, and it only worked because I knew the way the application code would have updated the table. And I should have written a better introduction, explaining our distributed application - where there were many fat client machines which could have been causing the problem.

My excuse is it was an immediate production issue - which for us (in manufacturing) means we lose £1000's per minute if production stops - we needed something quick. Fortunately the trigger worked and fairly quickly we identified a machine where a recent application code update had failed, so the trigger wasn't in production for long.

I was so proud of finding the problem without having to check all the fat clients individually to see if the update had been applied - I didn't vet my submission for general application.
Post #609970
Posted Monday, December 6, 2010 10:14 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, June 14, 2011 10:22 AM
Points: 64, Visits: 252
Hello Vladen,

I was testing your code. Where did you get the Deleted and Inserted tables from?

Thanks!
Post #1030722
Posted Tuesday, December 7, 2010 2:32 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Sunday, August 3, 2014 3:41 PM
Points: 1,219, Visits: 1,430
The DELETED and INSERTED tables are built into SQL Server for use with Triggers.

See this MSDN page
http://msdn.microsoft.com/en-us/library/ms191300.aspx

Post #1031087
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse