April 18, 2013 at 10:26 pm
Comments posted to this topic are about the item Triggers 1
April 18, 2013 at 10:29 pm
Thanks Hugo. Good question.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
April 18, 2013 at 10:54 pm
Thanks Hugo..
If insert statement was within Explicit transaction then even first row will not be inserted and the result of final query will be 0. Am I right?
Whether XACT_ABORT can play any role here?
--
Dineshbabu
Desire to learn new things..
April 18, 2013 at 11:40 pm
oopes,
I think I have misunderstood the way to execute the given query...
After seeing comments First Attempts, second, third I executed one by one those insert query and forget about the GO batch separator... and I was thinking it was so easy question and count will give 3 but i was wrong and lost the points... 🙁
I think most of the think count value as 3 and executed in same fashion that I executed that's why load towards incorrect answer is more than correct answer...
_______________________________________________________________
To get quick answer follow this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
April 19, 2013 at 12:18 am
Very good question hugo 🙂
In the starting of question, i come with answer 3. But suddenly i check "go", and game changed. 😀
Good question with good trick.
Thanks
Vinay Kumar
-----------------------------------------------------------------
Keep Learning - Keep Growing !!!
April 19, 2013 at 12:29 am
Dineshbabu (4/18/2013)
If insert statement was within Explicit transaction then even first row will not be inserted and the result of final query will be 0. Am I right?
Yes (assuming you start the transaction after the table creation and before the first insert). The ROLLBACK TRAN in the trigger will rollback the active transaction. In the code as posted, each INSERT starts its own implicit transaction which is committed (or rolled back) at the end of the statement. If you explicitly start a transaction before the first insert, then no implicit transactions will be started. And the ROLLBACK TRAN in the trigger will roll back that explicit transaction.
Whether XACT_ABORT can play any role here?
No. XACT_ABORT has an effect on errors that do not normally cause a rollback in an explicit transaction. In the code as posted, there is no explicit transation, so that alone means that XACT_ABORT has no effect. Adding an explicit transaction doesn't change that, as the error in this code already causes a rollback - so there is nothing for XACT_ABORT to do that the trigger code doesn't already do.
By the way, it's very easy to check this kind of questions for yourself. Just copy the code in SSMS, make changes, and see what happens. (Don't do this on a production database, or even on a production instance!)
April 19, 2013 at 12:32 am
kapil_kk (4/18/2013)
oopes,I think I have misunderstood the way to execute the given query...
Oohhh, I am so sorry that the comments in the code made you misunderstand the question. I added them to be able to refer to them in the explanation, not for any other reason, and I'm sorry if that caused people to come to wrong conclusions.
The next question in this series is scheduled for next week. Since it's already scheduled for publication, I cannot change it, or even see it anymore. That's how this site works. If my memory is not playing tricks on me, that question, too, will have similar comments. So please don't fall for that again!
April 19, 2013 at 12:44 am
Thanks for the question Hugo - nice and easy to end the week on
-------------------------------Posting Data Etiquette - Jeff Moden [/url]Smart way to ask a question
There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand (the world). There is no such thing as a dumb question. ― Carl Sagan
I would never join a club that would allow me as a member - Groucho Marx
April 19, 2013 at 1:22 am
Hugo, Question title is "Triggers 1", so everybody look at trigger (even be also). But trick was in "GO"
I think question title should be "GO". 🙂
Thanks
Vinay Kumar
-----------------------------------------------------------------
Keep Learning - Keep Growing !!!
April 19, 2013 at 1:40 am
Danny Ocean (4/19/2013)
Hugo, Question title is "Triggers 1", so everybody look at trigger (even be also). But trick was in "GO"I think question title should be "GO". 🙂
Try what happens if you use a CHECK constraint instead of a trigger to prevent negative values.
By the way, my questions never intentionally contain "tricks". I try to test knowledge. In this case, I focus on how a rollback from a trigger affects a batch.
I realize, from another posters' comment, that the comments in the code were misleading to some. I am really sorry for that. I absolutely do not want to trick people; I want to test their knowledge (and add to it, of course)
April 19, 2013 at 1:55 am
Hi,
There is one subtle issue with the explanation (and also the MS documentation).
It is not the ROLLBACK that is causing the abort of the batch. Instead, the batch is aborted if there is no transaction alive after the end of the trigger (at least that's what I can see from my tests).
For example, adding a BEGIN TRAN right after the ROLLBACK TRAN ensures that the batch is not aborted.
Best Regards,
Chris Büttner
April 19, 2013 at 2:04 am
Thanks for your reply Hugo.
Hugo Kornelis (4/19/2013)
By the way, it's very easy to check this kind of questions for yourself. Just copy the code in SSMS, make changes, and see what happens. (Don't do this on a production database, or even on a production instance!)
My intention of posting these kind of questions here is to make other beginners to learn few topics related to it as well as I can get various suggestions from many experts..
--
Dineshbabu
Desire to learn new things..
April 19, 2013 at 2:10 am
Hugo Kornelis (4/19/2013)
kapil_kk (4/18/2013)
oopes,I think I have misunderstood the way to execute the given query...
Oohhh, I am so sorry that the comments in the code made you misunderstand the question. I added them to be able to refer to them in the explanation, not for any other reason, and I'm sorry if that caused people to come to wrong conclusions.
The next question in this series is scheduled for next week. Since it's already scheduled for publication, I cannot change it, or even see it anymore. That's how this site works. If my memory is not playing tricks on me, that question, too, will have similar comments. So please don't fall for that again!
Thanks Hugo, question was good and I have gained something from this question that how a rollback from a trigger affects a batch...:-)
For the next question I will keep comments things in my mind 😛
_______________________________________________________________
To get quick answer follow this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
April 19, 2013 at 2:18 am
Christian Buettner-167247 (4/19/2013)
Hi,There is one subtle issue with the explanation (and also the MS documentation).
It is not the ROLLBACK that is causing the abort of the batch. Instead, the batch is aborted if there is no transaction alive after the end of the trigger (at least that's what I can see from my tests).
For example, adding a BEGIN TRAN right after the ROLLBACK TRAN ensures that the batch is not aborted.
Yes, you are correct. The batch is aborted because no transaction was open when the trigger finished executing. If you change the ROLLBACK in the trigger to COMMIT (though why on earth you'd want to???), the batch still aborts.
April 19, 2013 at 2:36 am
kapil_kk (4/18/2013)
oopes,I think I have misunderstood the way to execute the given query...
After seeing comments First Attempts, second, third I executed one by one those insert query and forget about the GO batch separator... and I was thinking it was so easy question and count will give 3 but i was wrong and lost the points... 🙁
I think most of the think count value as 3 and executed in same fashion that I executed that's why load towards incorrect answer is more than correct answer...
Result of 3 will be given, if GO exists after this insert
-- Insert attempt #2
INSERT INTO dbo.Test (PrimKey, ValueCol)
VALUES (2, -2);
GO
Regards
IgorMi
Igor Micev,My blog: www.igormicev.com
Viewing 15 posts - 1 through 15 (of 33 total)
You must be logged in to reply to this topic. Login to reply