|
|
|
SSCarpal Tunnel
       
Group: General Forum Members
Last Login: Today @ 7:45 AM
Points: 4,723,
Visits: 3,491
|
|
|
|
|
|
Old Hand
      
Group: General Forum Members
Last Login: Wednesday, November 04, 2009 8:19 AM
Points: 350,
Visits: 1,339
|
|
Johan,
Great article. That looks like quick thinking. How long did it take to figure out the Isolation-level problem? There is a moral for everyone in this story. DAC will, some day, save your bacon.
Best wishes,
Phil Factor Simple Talk
|
|
|
|
|
Hall of Fame
       
Group: General Forum Members
Last Login: Monday, November 02, 2009 9:26 AM
Points: 3,280,
Visits: 962
|
|
|
|
|
|
SSCarpal Tunnel
       
Group: General Forum Members
Last Login: Today @ 7:45 AM
Points: 4,723,
Visits: 3,491
|
|
Thank you for the comments.
Fortunately it didn't take me that much time to figure out the issue  I'm always using my version of sp_who to see what's going on in an instance.
That proc shows me isolationlevels, ....
I'm one of the happy few that has a mainframe background , so one of the first points of interest is the isolation level of a connection.
Also ... one of the error log messages stated : ...attempted to unlock a resource it does not own... which may point to a transaction related problem.
Don't drive faster than your guardian angel can fly ... but keeping both feet on the ground won't get you anywhere 
Very usefull HowTo for forums: - How to post Performance Problems - How to post data/code to get the best help
|
|
|
|
|
SSCrazy Eights
        
Group: General Forum Members
Last Login: 2 days ago @ 4:56 PM
Points: 8,401,
Visits: 7,821
|
|
|
|
|
|
SSCrazy Eights
        
Group: General Forum Members
Last Login: 2 days ago @ 4:56 PM
Points: 8,401,
Visits: 7,821
|
|
I agree with you Johan, it is important to remember that unlike their corresponding DDL events, DDL triggers do execute synchronously and in the source execution context. Consequently they do always have some effect on the source process and activity.
My general rule of thumb is that you should always prefer to use DDL Event notification over DDL triggers, unless you actually do want to have some effect on the triggering process or command (such as intentionally rejecting certain Logins).
-- RBarryYoung, (302)375-0451 blog: MovingSQL.com, Twitter: @RBarryYoung Proactive Performance Solutions, Inc. "Performance is our middle name."
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Tuesday, November 03, 2009 4:14 PM
Points: 6,123,
Visits: 1,557
|
|
Excellent war story.
I think Rbarryyoung is right on the money. I believe that the lack of explicit transaction demarcation is the real problem. Do you mind specifying explicit "begin tran"/"commit tran" ? It should work, right?
* Noel
|
|
|
|
|
SSCarpal Tunnel
       
Group: General Forum Members
Last Login: Today @ 7:45 AM
Points: 4,723,
Visits: 3,491
|
|
rbarryyoung (12/15/2008) I agree with you Johan, it is important to remember that unlike their corresponding DDL events, DDL triggers do execute synchronously and in the source execution context. Consequently they do always have some effect on the source process and activity.
My general rule of thumb is that you should always prefer to use DDL Event notification over DDL triggers, unless you actually do want to have some effect on the triggering process or command (such as intentionally rejecting certain Logins).
noeld (12/15/2008) Excellent war story.
I think Rbarryyoung is right on the money. I believe that the lack of explicit transaction demarcation is the real problem. Do you mind specifying explicit "begin tran"/"commit tran" ? It should work, right?
Well, I will try to test it in collaboration with my biztalk dev team.
But I think it would be over simplified to just incorporate the explicit "begin tran"/"commit tran". E.g. when using implicit transactions, one should also have to check for the @@trancount !, and then basically violate the concept of the implicit transaction itself.
Secondly, considered the absence of the need to interfere in realtime, the only valid approach is the one using sqlserver events.
Don't drive faster than your guardian angel can fly ... but keeping both feet on the ground won't get you anywhere 
Very usefull HowTo for forums: - How to post Performance Problems - How to post data/code to get the best help
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Monday, October 26, 2009 12:27 PM
Points: 110,
Visits: 26
|
|
Could you not have just added:
set transaction isolation level read committed
after the "set nocount on" in the trigger to set the isolation level for the duration of the trigger execution. Surely using the events is ultimately better, but that should have fixed it.
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Wednesday, October 07, 2009 2:39 AM
Points: 1,
Visits: 14
|
|
Very useful and dramatic story! The asynchronous approach is always preferable for me so long as I don't like to do something immediately (e.g. rollback or blocking). Thanks for share.
|
|
|
|