March 4, 2002 at 9:58 am
Haven't tried it, and I'm sure Microsoft would have fits about the whole thing.
One thing to consider with the trigger, though, is that it will fire per the operation specified, whether it be INSERT, UPDATE, or DELETE. Once we start execution of the trigger, we can determine if we need to drop out early, but the overhead cost is still incurred for starting up the trigger. As a result, I'm not so sure putting a trigger on a system table, even if doable, is such a great idea.
K. Brian Kelley
http://www.sqlservercentral.com/columnists/bkelley/
K. Brian Kelley
@kbriankelley
March 4, 2002 at 10:07 am
I already have a process that captures only deadlock spids and then captures what the spids are doing and all this occurs before SQL Server kills one of the processes as the deadlock victim.
The reason I have considered using a trigger is because every other way I have tried uses too much of the processor time to constantly scan for deadlocks.
I keep investigating things that end up being better not done, even though they could work. Oh well, its a good learning experience.
Robert Marda
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply