InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comThu, 20 Jun 2013 00:17:13 GMT20http://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxA poorly worded trick question.Thu, 24 Nov 2011 14:07:28 GMTWelsh Corgihttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxLiked the use of TRY...CATCH (though checking XACT_STATE would be cool).Disliked the loop.On balance: not bad.Tue, 30 Mar 2010 10:32:11 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxI like to think of the right answer as being the one "closest" to being right, which was the right answer which I chose despite knowing that the output did not look exactly correct but could not possibly be the other choices in any order.Another good exercise for the kiddies in class! Keep those QOTD's coming!Mon, 15 Mar 2010 22:36:51 GMTPeter Trasthttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]srinivas.thadem (2/2/2010)[/b][hr]I really disagrree with the answer 1245.the actual resul it is 12345.if @i = 3 then we are setting J = @i/0;so there no use of this statement finally we are storing the i value in to the temparory table.[/quote]You can't divide by 0.... unless your name is Chuck Norris.Wed, 03 Feb 2010 06:44:52 GMTFatal Exception Errorhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxI really disagrree with the answer 1245.the actual resul it is 12345.if @i = 3 then we are setting J = @i/0;so there no use of this statement finally we are storing the i value in to the temparory table.Tue, 02 Feb 2010 01:18:25 GMTsrinivas.thademhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxThe answer is arguably correct since an exception occurs and is handled in the code. The order of what appears, and where, depends on your client.The question has been edited to separate out "results" and "messages"Fri, 29 Jan 2010 09:56:12 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxHi, This question havn't right answer.at condition when i = 3 then exception will be occur , in that case transaction not commit and rollback in catch block, so that record will not inter in the #temp..That why Select * from # Temp, will give the following answer...1245Please Check you question and answer before post.Fri, 29 Jan 2010 09:43:34 GMTShahd Ansarihttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]COldCoffee (1/29/2010)[/b][hr][quote][b]Mohammad Irfan-488206 (1/28/2010)[/b][hr]Output answer should be 1245why this option was not there??[/quote]I guess u did not look up at the "Messages" tab in the Results Pane..For those intending to get the exact answer given in the choices, run this code[code="sql"]set nocount ondrop table #tempdeclare @i int, @j int set @i = 1create table #temp (id int) while (@i<=5) begin begin try begin transaction if (@i = 3) set @j = @i/0 insert into #temp values (@i) print cast (@i as varchar(5)) commit transaction end try begin catch rollback transaction print 'this is an exception'; end catch set @i = @i + 1 end[/code]Excellent question to learn exception-catching in a loop...[/quote]Ok thanks, but the question was about what will be the output, not message, else you may get many messages like 1 row affected...Fri, 29 Jan 2010 01:38:40 GMTHardCoderhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]Mohammad Irfan-488206 (1/28/2010)[/b][hr]Output answer should be 1245why this option was not there??[/quote]I guess u did not look up at the "Messages" tab in the Results Pane..For those intending to get the exact answer given in the choices, run this code[code="sql"]set nocount ondrop table #tempdeclare @i int, @j int set @i = 1create table #temp (id int) while (@i<=5) begin begin try begin transaction if (@i = 3) set @j = @i/0 insert into #temp values (@i) print cast (@i as varchar(5)) commit transaction end try begin catch rollback transaction print 'this is an exception'; end catch set @i = @i + 1 end[/code]Excellent question to learn exception-catching in a loop...Fri, 29 Jan 2010 01:23:11 GMTColdCoffeehttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxthe select only returns 1 2 4 5 .this is an exception is not returned by the select, so actually i don't feel this is a good question.I knew which one to choose but it's not 100% correct.Thu, 28 Jan 2010 08:36:26 GMTwim.buyenshttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxOutput answer should be 1245why this option was not there??Thu, 28 Jan 2010 00:03:47 GMTHardCoderhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxLearnt some thing . But does'nt Set ansi_warning have an impact.Fri, 22 Jan 2010 05:26:56 GMTChiragNShttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]Saurabh Dwivedy (1/21/2010)[/b][hr]<snip>My only submission is for us to be a little more considerate for the poster. Someone has spent some time and effort creating the question. Creating is not an easy business and I quite liked the frankness displayed by another poster on the forum who openly accepted he wasn't quite wired for doing such a thing. Let's be a little considerate, folks. Let's also keep in mind that even those posting the questions may not be experts at creating questions.<snip>RegardsSaurabh[/quote]Hear hear!Fri, 22 Jan 2010 01:41:04 GMTKelsey Thorntonhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxHi,The CATCH clause in SQL server does exactly what a catch(Exception ex) in C# does. Also the ROLLBACK is perfectly valid; imagine what would happen if there was no TRY.. CATCH within the given sample code. In that case after opening a transaction, there would be a divide by zero error and this is analogous to an error in the transaction which would eventually result in it's roll back.Thu, 21 Jan 2010 10:39:05 GMTprahaladdhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxI too, like most others, initially felt inclined to believe none of the answers was PERFECTLY CORRECT because the text - in the middle of the answer set - was a bit misleading - mainly because everyone expected the OUTPUT to come from the select * from #temp, which could not "emit" the output displayed in the answer choices. However, I chose the right answer because there didn't seem to be any other answer coming close. The "right answer" had all the ingredients though not exactly in the 'proper way'.I see both sides of the argument - one asserting that "There is no correct answer" and the other inviting us to focus on the "larger picture". My only submission is for us to be a little more considerate for the poster. Someone has spent some time and effort creating the question. Creating is not an easy business and I quite liked the frankness displayed by another poster on the forum who openly accepted he wasn't quite wired for doing such a thing. Let's be a little considerate, folks. Let's also keep in mind that even those posting the questions may not be experts at creating questions. I don't think we have folks dedicated here to proof-read questions thoroughly before the questions are printed. If we are so irked by "inappropriate/incorrect" question why don't we form a volunteer group (on a revolving basis maybe) who would do the needful. Somebody brought GRE type questions into the picture which was again very surprising. This is a forum for learning and sharing. Let's give kudos and help make this forum a great learning experience for everyone. If anything - pure criticism without being properly backed by a plan of action to fix the source of criticism is a sheer waste of time IMHO.RegardsSaurabhThu, 21 Jan 2010 09:41:36 GMTSaurabh Dwivedyhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]pg53 (1/21/2010)[/b][hr]Apart from that, what's going on with the transaction? ... that rollback in the middle - can you do that?[/quote]You can roll back a transaction in the middle, in the end, or even in the beginning of a batch – it's no problem with that :-)Thu, 21 Jan 2010 08:38:01 GMTvk-kirovhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxthat's because the 'correct' answer wasn't correct.Thu, 21 Jan 2010 07:49:23 GMTnomladhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxI am assuming one of the answers has to be correct. It's just that the "correct" answer isn't really in the form that my result window showed. We got the point though.Thu, 21 Jan 2010 07:14:15 GMTcrussell-931424http://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxApart from that, what's going on with the transaction? Nobody's mentioned that, but isn't that kind of weird? (Don't shoot me if it's obvious, I'm primarily a .Net guy rather than a DBA, so Try . . .Catch was familiar ground; but that rollback in the middle - can you do that?)Thu, 21 Jan 2010 04:13:28 GMTpg53http://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxNice QoTD :-).An important point to remember is that a TRY..CATCH can be used to catch all database errors having the error number >10 that do not terminate a database connection.MSDN has more information on this.http://msdn.microsoft.com/en-us/library/ms175976.aspxWed, 20 Jan 2010 22:44:32 GMTprahaladdhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxAgreed, Jason. The intent of the question was good and purposeful, no doubt.Funny that most of us, as technologists, are so insistent on a perfectly valid scenario. :) The point wasn't lost on me, but I am adamant about well thought-out surveys. I remain left to wonder, for example, how much thought went into this question and for what reasons. This is and will be my main reason for engaging in this discussion, as has been my practice in prior discussions.Wed, 20 Jan 2010 15:47:26 GMTRichard Farrishttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]Lynn Pettis (1/20/2010)[/b][hr][quote][b]mzz3lh (1/20/2010)[/b][hr]I have to agree here. None of the answers match what I would expect, which would be 'This is an exception' in the message pane, followed by the contents of the temp table: 1, 2, 4, 5.However, when I ran this to try it out, I got an error:[quote](1 row(s) affected)(1 row(s) affected)this is an exceptionMsg 208, Level 16, State 0, Line 10Invalid object name '#temp'.[/quote]Which indicates that despite the try-catch block, the error caused the temp table to be dropped mid-execution.[/quote]Or that something was wrong with the code you ran. It ran fine for me, and it appears from a few other posts that it ran fine for others.I agree, the answers may not have been displayed as many of us have seen it when we ran the code. The question is, were you able to correctly predict the output? In this case, as mentioned in another post, there really was only one option that could be correct. It may have been more difficult had there been one or two more possible answers with the exception message included.[/quote]Agreed here, there is only one answer that supplies both pieces of the answer. All other answers were invalid.Settings in your SSMS would cause slightly different output. One scenario includes set nocount, and whether or not it is on or off.set nocount on gives me the following in the message pane:this is an exceptionset nocount off gives the following(1 row(s) affected)(1 row(s) affected)this is an exception(1 row(s) affected)(1 row(s) affected)(4 row(s) affected)I think being overly picky about the presentation of the available answer in this scenario is going beyond what the question was trying to derive.We have been shown that both parts of the correct answer are only available in one of the answers.Wed, 20 Jan 2010 15:32:31 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxJust so you know, Lynn, I appreciate your insights, especially on items such as the QotD.I did find the answers a little ambiguous, but I learned a bit more about analysis.Thanks.Kevin C.Wed, 20 Jan 2010 11:14:47 GMTKevinC.http://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]Fatal Exception Error (1/20/2010)[/b][hr][quote][b]Lynn Pettis (1/20/2010)[/b][hr]It isn't just the QotD that you can learn from, but also the discussion that may follow (as long as you ignore the complaints).Does SSC vet the questions, to a point, but not nearly as well as some people would like to see. Of all the questions I have answered, I think I only really had a serious complaint about one or two. Yes, there are issues with some of the questions, but if you look closer at the concept that the question is trying to address, and less on the question and answers themself, I think you will learn something.Take today's question. Based on the answers, you'd have expected there to be PRINT statements in the question but there wasn't. If you understand the concept of the TRY/CATCH, and that the divide by zero would be caught and handled in the CATCH part of the code, there really was only one answer that made sense, and it happened to be the only one with the message from the PRING statment in the CATCH block.[/quote]I strongly disagree. I am not trying to be a jerk but this is not the first time people have complained about ambiguous answers from arup.What concept do new people get from incorrect answers as options? None of the answers fit at all. The fact that you assumed you knew what the author meant and selected your answer based on an assumption and not knowing proves this. What if I assumed the author missed a PRINT @i.I learned nothing from this except: -there can be mingling between result set and messages in the answer for a QoTD.-It is now possible for an integer field to display a string in the answer for the QoTD.-Ambiguity is now acceptable for listed answers to the QoTD just like irregardless is now accepted as a word by dictionaries.[/quote]Okay. I'll shut up now.Wed, 20 Jan 2010 10:47:30 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]Lynn Pettis (1/20/2010)[/b][hr]It isn't just the QotD that you can learn from, but also the discussion that may follow (as long as you ignore the complaints).Does SSC vet the questions, to a point, but not nearly as well as some people would like to see. Of all the questions I have answered, I think I only really had a serious complaint about one or two. Yes, there are issues with some of the questions, but if you look closer at the concept that the question is trying to address, and less on the question and answers themself, I think you will learn something.Take today's question. Based on the answers, you'd have expected there to be PRINT statements in the question but there wasn't. If you understand the concept of the TRY/CATCH, and that the divide by zero would be caught and handled in the CATCH part of the code, there really was only one answer that made sense, and it happened to be the only one with the message from the PRING statment in the CATCH block.[/quote]I strongly disagree. I am not trying to be a jerk but this is not the first time people have complained about ambiguous answers from arup.What concept do new people get from incorrect answers as options? None of the answers fit at all. The fact that you assumed you knew what the author meant and selected your answer based on an assumption and not knowing proves this. What if I assumed the author missed a PRINT @i.I learned nothing from this except: -there can be mingling between result set and messages in the answer for a QoTD.-It is now possible for an integer field to display a string in the answer for the QoTD.-Ambiguity is now acceptable for listed answers to the QoTD just like irregardless is now accepted as a word by dictionaries.Wed, 20 Jan 2010 10:32:19 GMTFatal Exception Errorhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxI agree with the others here. The proffered answers were not adequate because there was too much ambiguity on what should be considered "output". If you are expecting that "output" is the result of the SELECT, then there was no correct answer. If you expected "output" to mean both messages and results, then the supposed correct answer is also not accurate.This question was just poorly worded. Try... Catch is a concept that is very important to understand though, so I appreciate the intent.Wed, 20 Jan 2010 09:05:41 GMTRichard Farrishttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]Lynn Pettis (1/20/2010)[/b][hr]To all those who are expecting PRECISELY CORRECT ANSWERS, how about putting yourself out there and submit some questions. The answers may not have been precise, but I don't feel that it really took that much away from the question. What was important was seeing that using the TRY/CATCH kept the while loop from being aborted, allowing you to control the processing within SQL itself.[/quote]I agree on both points - the imprecision detracted little from the question, and if someone wants better questions, they can always submit one of their own. In fact, with slight rewording, focusing on the precise output format is almost irrelevant:Instead of "Try to predict the output..." the question might have read: "Which choice best matches the expected results of the code?" (I think the term "results" covers both query messages and query output.)I can certainly see why someone would point out that the output given did not exactly match the results in the choices. Precision is to be desired when working with data. But it really comes down to whether you thought "this is an exception" would print as well as how many of the digits would appear in the final output. And to that end, the range of options seemed clear to me. If there had been another choice with the phrase "this is an exception" listed somewhere else in the output, then the objections would be stronger, IMHO.Wed, 20 Jan 2010 08:50:12 GMTwebrunnerhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]Brnbngls (1/20/2010)[/b][hr]I certainly dont' want to get into a criticizing of the QoTD. I have learned much from them. But being what I consider to be a SQL noob/beginner, I look to them sometimes for education. I feel that I'm becoming fairly proficient at reading code so when I looked over this one, I immediately recognized that the exception error message was a PRINT statement and not an insert. Therefore wouldn't have been in the SELECT results. Imagine my surprise when I got it wrong. Most of the time, if I get it wrong, I just accept it, read up on why I got it wrong and move on. Sometimes though, I think it's just a dumb mistake and don't bother to look it up (it's why I struggled with SAT's). Questions like this where I'm pretty confident I know the answer and then see that I'm wrong frustrate me as someone who's still learning. When I think I have a concept down, the answer tells me I don't, I get befuddled and don't want to continue. Glad I came in here for validation today though.As for submitting my own QoTD as another poster suggests, not a chance. I couldn't come up with anything challenging enough for most of the folks here. I'd get laughed off the boards I'm sure. I'm just not wired that way. But when I come here looking to bolster my education and get further confused, that's not good practice. I applaud those that do post questions though, way to get out there and be bold. But are the questions and answers verified by SSC.com folks prior to posting live?I'll get down off the soapbox now. Thanks for reading.[/quote]It isn't just the QotD that you can learn from, but also the discussion that may follow (as long as you ignore the complaints).Does SSC vet the questions, to a point, but not nearly as well as some people would like to see. Of all the questions I have answered, I think I only really had a serious complaint about one or two. Yes, there are issues with some of the questions, but if you look closer at the concept that the question is trying to address, and less on the question and answers themself, I think you will learn something.Take today's question. Based on the answers, you'd have expected there to be PRINT statements in the question but there wasn't. If you understand the concept of the TRY/CATCH, and that the divide by zero would be caught and handled in the CATCH part of the code, there really was only one answer that made sense, and it happened to be the only one with the message from the PRING statment in the CATCH block.Wed, 20 Jan 2010 08:48:18 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxI certainly dont' want to get into a criticizing of the QoTD. I have learned much from them. But being what I consider to be a SQL noob/beginner, I look to them sometimes for education. I feel that I'm becoming fairly proficient at reading code so when I looked over this one, I immediately recognized that the exception error message was a PRINT statement and not an insert. Therefore wouldn't have been in the SELECT results. Imagine my surprise when I got it wrong. Most of the time, if I get it wrong, I just accept it, read up on why I got it wrong and move on. Sometimes though, I think it's just a dumb mistake and don't bother to look it up (it's why I struggled with SAT's). Questions like this where I'm pretty confident I know the answer and then see that I'm wrong frustrate me as someone who's still learning. When I think I have a concept down, the answer tells me I don't, I get befuddled and don't want to continue. Glad I came in here for validation today though.As for submitting my own QoTD as another poster suggests, not a chance. I couldn't come up with anything challenging enough for most of the folks here. I'd get laughed off the boards I'm sure. I'm just not wired that way. But when I come here looking to bolster my education and get further confused, that's not good practice. I applaud those that do post questions though, way to get out there and be bold. But are the questions and answers verified by SSC.com folks prior to posting live?I'll get down off the soapbox now. Thanks for reading.Wed, 20 Jan 2010 08:24:48 GMTBrnbnglshttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]Raj The King (1/20/2010)[/b][hr]The original choices do not contain correct answers..Please Dont Post like this questions..yesterday also same...question is correct but answer is not in the list...! Again Today Same...![/quote]Okay, would you please submit a QotD?Wed, 20 Jan 2010 08:06:06 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]jswong05 (1/20/2010)[/b][hr]The original choices do not contain correct answers. Please verify the Q/A before it is published.Imagine you take a GRE special topic test that involes world wide thousands of thousands people on the same day, and in the middle you found there is a question there has no correct answer. We have to guess what it was asking. This is the test that determine your fate.Try-catch was invented 20 years ago when I coded C++, it is nice to see people starts understanding it in SQL community.[/quote]I'm really sorry if you think the QotD and GRE are even remotely equivalent. I would definately expect the questions on the GRE to heavily fetted as the GRE is used to determine acceptance to many Graduate programs. The QotD is nothing as serious as that. To expect that is, to me, unrealistic.Wed, 20 Jan 2010 08:05:21 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxThe original choices do not contain correct answers..Please Dont Post like this questions..yesterday also same...question is correct but answer is not in the list...! Again Today Same...!Wed, 20 Jan 2010 08:00:40 GMTSree Arjun Divhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote]The problem with the correct answer not being one of the options is that it confuses junior and intermediate level folks (I would consider myself intermediate as there is a ton about SQL Server that I don't know.)[/quote]This right here.When I saw none of the possible answers matched what I expected I assumed my understanding of how things works was wrong. I knew 3 could not be in the answer. I also knew you could not get a string out of an int field. That left me with only one other choice.The question was good. The selection of answers was abysmal.Wed, 20 Jan 2010 07:58:07 GMTFatal Exception Errorhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxI had a bit of problem as well with "invalid object name #temp" AT FIRST - wierd.I changed it to #ttt and it worked right away. Dropped #ttt and changed back to #temp and it worked away. [code="sql"]Set no count on[/code] - doesn't hurt either and probably should have been included in the teaser. Changing output to text as opposed to grids (Ctrl +T for text out and Ctrl + D for grid output) gave me this output:[code="other"]this is an exceptionid-----------1245[/code]And here is my formatted code snippet with tab formatting - btw I read in a previous thread that "this code snippet is what most us would have liked to have seen" - I agree:[code="sql"]drop table #tempcreate table #temp (id int)declare @i int, @j intset @i = 1while (@i<=5) begin begin try begin transaction if (@i = 3) set @j = @i/0 insert into #temp values (@i) commit transaction end try begin catch print 'this is an exception'; rollback transaction end catch set @i = @i + 1 endselect * from #temp[/code]So what is the SSC correct answer to this problem? Although div by zero is certainly going to throw and exception and the concept of this teaser is exception handling in TSQL - has there been a consensus as to what the correct answer is?-MikeWed, 20 Jan 2010 07:57:19 GMTMike DiRenzohttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxOK, partial credit it is then :-)Wed, 20 Jan 2010 07:55:24 GMTnomladhttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxI'm sure most of you complaining would have preferred to have seen this as the code:[code="sql"]declare @i int, @j intset @i = 1while (@i<=5)begin begin try begin transaction if (@i = 3) set @j = @i/0 print @i commit transaction end try begin catch rollback transaction print 'this is an exception'; end catch set @i = @i + 1 end[/code]This way, the answers are precise. This is what I looked for at first based on the answers provided. But not seeing this as the code did not change which answer I chose.Wed, 20 Jan 2010 07:54:06 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]nomlad (1/20/2010)[/b][hr]It was fairly easy to see the concept which was being put across here regarding try/catch blocks - not exactly a new one for most developers these days I should imagine. But if I'd posed that question in an interview and the candidate had given the answer given as correct I would not have marked it as correct.The answer given as correct implies that the text of the error message was somehow inserted into the table and then returned as part of the result set - completely wrong.[/quote]Is it wrong? Look a little closer, did the individual understand how the code itself worked? Maybe the output was formated wrong, but the content correct. You can always work with someone to make sure they have better understanding of how the output would actually be presented, but they would have at least demonstrated an understanding of the concepts. In the case of an interview, I'd have to give partial credit at least.Wed, 20 Jan 2010 07:49:39 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspxThe original choices do not contain correct answers. Please verify the Q/A before it is published.Imagine you take a GRE special topic test that involes world wide thousands of thousands people on the same day, and in the middle you found there is a question there has no correct answer. We have to guess what it was asking. This is the test that determine your fate.Try-catch was invented 20 years ago when I coded C++, it is nice to see people starts understanding it in SQL community.Wed, 20 Jan 2010 07:39:49 GMTjswong05http://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]Lynn Pettis (1/20/2010)[/b][hr]... What was important was seeing that using the TRY/CATCH kept the while loop from being aborted, allowing you to control the processing ...[/quote]I totally agree. This was a great example of how to loop and do conditional processing with error handling and without a cursor. Excellent question, I made some edits and comments and have saved it for future reference.[code="sql"]declare @i int, @j intset @i = 1create table #temp (id int)while (@i<=5)begin -- while loop begin try -- trap errors begin transaction if (@i = 3) set @j = @i/0 insert into #temp values (@i) -- insert values when there are no errors print '@i = [' + Convert(varChar(8), @i) + ']' commit transaction end try begin catch -- handle errors rollback transaction print 'An error was caught when @i = [' + Convert(varChar(8), @i) + ']'; end catch set @i = @i + 1 end -- while loopselect * from #tempdrop table #temp[/code]Wed, 20 Jan 2010 07:36:18 GMTDave62http://www.sqlservercentral.com/Forums/Topic850204-1391-1.aspx[quote][b]Lynn Pettis (1/20/2010)[/b][hr]To all those who are expecting PRECISELY CORRECT ANSWERS, how about putting yourself out there and submit some questions. The answers may not have been precise, but I don't feel that it really took that much away from the question. What was important was seeing that using the TRY/CATCH kept the while loop from being aborted, allowing you to control the processing within SQL itself.[/quote]Here I was going to complain about the correct answer not being one of the options but I was beaten to it several times over!The problem with the correct answer not being one of the options is that it confuses junior and intermediate level folks (I would consider myself intermediate as there is a ton about SQL Server that I don't know.)By the way, is it just me, or is your signature getting longer? :hehe:Wed, 20 Jan 2010 07:28:26 GMTConan The Canadian