tag:blogger.com,1999:blog-8677649049588007585.post4741368444241824392..comments2023-06-18T16:15:22.432+01:00Comments on PL/SQL Challenge: 26 October quiz: objections to marking a choice as incorrect (1583)Steven Feuersteinhttp://www.blogger.com/profile/16619706770920320550noreply@blogger.comBlogger28125tag:blogger.com,1999:blog-8677649049588007585.post-54544487512724585422010-10-28T22:17:15.349+01:002010-10-28T22:17:15.349+01:00Hello All,
Relative to Scott's remark:
Yes, th...Hello All,<br />Relative to Scott's remark:<br />Yes, the READ ONLY transactions are treated in the PL/SQL User Guide, just like most of the DML statements are presented, but it is still not a "pure" (or typical) PL/SQL topic.<br /><br />I understand the arguments of both parts,<br />but I think that maybe a final argument for considering this choice as INCORRECT is the following simple one:<br /><br />There are countless scenarios (pl/sql blocks)<br />where you CAN really put SET TRANSACTION anywhere in the executable part (ex.blocks running in a session that issues SELECT-s only), as well as there are countless scenarios in which putting SET TRANSACTION anywhere will NOT work.<br /><br />The "spirit" of the choice was probably this:<br />"SET TRANSACTION will ALWAYS work in ANY pl/sql block, wherever in the block I place it."<br /><br />This is clearly NOT true, so I think that ultimately scoring it as INCORRECT was the right thing to do.<br /><br />Best Regards,<br />Iudith Mentzeliudithhttps://www.blogger.com/profile/04905902445036068357noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-85487904715803383722010-10-28T21:20:22.660+01:002010-10-28T21:20:22.660+01:00I think, Jhall62, that we will have to agree to di...I think, Jhall62, that we will have to agree to disagree. I do not interpret the statement the way that you do. I do not see how identifying a single scenario where the STRO statement can appear a SQL statement, like a select, makes that choice correct.<br /><br />SFSteven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-7398071158338915132010-10-28T19:54:10.400+01:002010-10-28T19:54:10.400+01:00Steven, although I understand that it is not the r...Steven, although I understand that it is not the reason you scored this choice as you did, arguing that this choice is incorrect because the phrase “statement can appear anywhere in your PL/SQL block” does not exclude the declaration section is disingenuous and scoring responses on such a basis would take the PL/SQL Challenge into the realm of trick questions. If discussions of executable statements are not implicitly limited to the executable portions of PL/SQL blocks then I am certain that there are other quizzes that should have been scored differently.<br /><br />The original choice was stated as follows (emphasis mine):<br /><br />"The SET TRANSACTION READ ONLY statement <i>can</i> appear anywhere in your PL/SQL block, regardless of the <i>location</i> of SQL statements in that block."<br /><br />There is absolutely nothing in the wording that limits the <i>type</i> of SQL statement; therefore, the statement is true if there is at least one case in which the location of SET TRANSACTION READ ONLY is independent of the location of <i>some</i> SQL statement. Previous comments in this thread have already demonstrated that a plain SELECT (without FOR UPDATE) can be positioned anywhere relative to SET TRANSACTION READ ONLY and will not raise an exception or a compile error so long as SET TRANSACTION READ ONLY does not occur within an open transaction.<br /><br />I understood the intent of the choice, and chose not to select it; however, it is possible (even likely) others may have evaluated it as I have just described. The question asked "which of these statements…are correct?" No other criteria were stated (although the implicit requirement that it compile and execute without raising an exception should be apparent to everyone). From a strictly literal and logical perspective, those who selected this choice are correct.<br /><br /><br />Dennis, SET TRANSACTION READ ONLY, and any other statements that can be directly executed in PL/SQL, should not be wrapped inside EXECUTE IMMEDIATE. There are several reasons for this, chief among them being that it prevents the compiler from identifying errors in the wrapped statement. EXECUTE IMMEDIATE should be reserved for dynamic SQL or SQL that cannot be handled directly in PL/SQL, such as DDL.jhall62https://www.blogger.com/profile/10339038131928463003noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-72098775263384834982010-10-28T14:38:58.998+01:002010-10-28T14:38:58.998+01:00Vitaliy,
> Knowledge doesn't count. Guessi...Vitaliy,<br /><br />> Knowledge doesn't count. Guessing of mood counts.<br /><br />Most probably neither will your employer fire you nor will your customers disregard you because you weren't 100% correct in the PL/SQL Challenge. Most probably (hopefully) you weren't planning to put a "One-time monthly winner in the weekly PL/SQL Challenge" in your CV. <br /><br />So - why be so dogged about this?<br /><br />It may be a matter of attitude, but when I got an answer wrong (like I did yesterday) because of a possible ambiguity, I can tell myself "I know what I know and I know I understood the topic completely". And when I see that I WAS wrong, then I'll be happy because I've gained experience. And then I get back to work, where knowledge that counts is more than just checking the right box.<br /><br />This quiz is a win/win for me. A lotto isn't.<br /><br />So far for my .02 €,<br />UweUwe Küchlerhttps://www.blogger.com/profile/08199596117280621443noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-7610726223539145312010-10-28T05:51:32.240+01:002010-10-28T05:51:32.240+01:00> "I don't see any way to justify mark...> "I don't see any way to justify marking this choice as correct"<br /><br />Knowledge doesn't count. Guessing of mood counts. It's a lotto. The further the more uninteresting.Vitaliy Lyanchevskiyhttps://www.blogger.com/profile/03394959689295703518noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-24271523114176043642010-10-28T02:20:02.854+01:002010-10-28T02:20:02.854+01:00I know I'm late on here, but if this wording w...I know I'm late on here, but if this wording was put into question, then you need to question the entire documentation library - because it's exactly how it reads. There is no issue!<br /><br />Iudith - this topic is found in Ch6 of the PL/SQL user's guide, so I don't think we're crossing boundaries.Scott Wesleyhttps://www.blogger.com/profile/18106937181788036683noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-9248524579982418252010-10-27T23:43:01.927+01:002010-10-27T23:43:01.927+01:00PART 2
2. I say "anywhere in your PL/SQL blo...PART 2<br /><br />2. I say "anywhere in your PL/SQL block", but transactions are connected to a session and not a block. In addition, many players offers scenarios in which the SET TRANSACTION was not the first statement in the block. Great points, but they do not mean that the choice should be marked as correct. This choice can only be correct if I can put the SET TRANSACTION READ ONLY anywhere in my block no matter where my SQL statements are and still have a valid read-only transaction. This is clearly NOT TRUE. If I put SET TRANSACTION READ ONLY after an update statement, Oracle will raise an error when I try to execute the block. So this very broad claim of "can appear anywhere" is clearly false.<br /><br />In fact, now that I think about it, I don't even say "can appear anywhere in the execution section of the PL/SQL block," so this choice can easily be rejected as correct, since you certainly can't put the statement in the declaration section of the block.<br /><br />To conclude: I don't see any way to justify marking this choice as correct. And I did not. It is incorrect. There is no reason for me to change the way I scored this quiz<br /><br />There were many comments in this thread; it is late (12:30 AM) and I am exhausted from a full day of training (and waking up at 4 AM yesterday). So I may have missed something. Please let me know me if you made a comment that you think is left unaddressed.<br /><br />Warm regards, StevenSteven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-31804099335529804312010-10-27T23:42:53.222+01:002010-10-27T23:42:53.222+01:00A very thoughtful and interesting thread of commen...A very thoughtful and interesting thread of comments. Thanks, everyone, for contributing.<br /><br />And now I offer some comments (in two parts, as Blogger seems to have a limit on the size. VERY irritating)....<br /><br />PART 1<br /><br />It seems that there were two objections regarding my decision to score this choice as incorrect: "The SET TRANSACTION READ ONLY statement can appear anywhere in your PL/SQL block, regardless of the location of SQL statements in that block."<br /><br />1. I only say "appear anywhere". I do not say that it must compile or must execute without error. So, sure, the argument goes, you can put the statement "anywhere." If I made the above statement as a "stand alone" claim and asked you to decide "true or false" on the basis of that statement alone, I could definitely see why you might argue that it is incomplete or ambiguous. But this is not a "stand alone" statement. It is proposed as an answer to a question. The question is:<br /><br />"Which of these statements regarding read-only transactions in PL/SQL are correct?"<br /><br />A "read-only transaction" only exists when you run a piece of code that includes the SET TRANSACTION READ ONLY statement. So I feel that the context of this question (in which you must evaluate each of the choices) is quite clear: the block of code containing SET TRANSACTION READ ONLY must compile and execute to be a read-only transaction.Steven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-73644741762249891322010-10-27T23:41:42.027+01:002010-10-27T23:41:42.027+01:00A very thoughtful and interesting thread of commen...A very thoughtful and interesting thread of comments. Thanks, everyone, for contributing.<br /><br />And now I offer some comments. <br /><br />It seems that there were two objections regarding my decision to score this choice as incorrect: "The SET TRANSACTION READ ONLY statement can appear anywhere in your PL/SQL block, regardless of the location of SQL statements in that block."<br /><br /><b>1. I only say "appear anywhere". I do not say that it must compile or must execute without error.</b> So, sure, the argument goes, you can put the statement "anywhere." If I made the above statement as a "stand alone" claim and asked you to decide "true or false" on the basis of that statement alone, I could definitely see why you might argue that it is incomplete or ambiguous. But this is not a "stand alone" statement. It is proposed as an answer to a question. The question is:<br /><br />"Which of these statements regarding read-only transactions in PL/SQL are correct?"<br /><br />A "read-only transaction" only exists when you run a piece of code that includes the SET TRANSACTION READ ONLY statement. So I feel that the context of this question (in which you must evaluate each of the choices) is quite clear: the block of code containing SET TRANSACTION READ ONLY must compile and execute to be a read-only transaction. <br /><br /><b>2. I say "anywhere in your PL/SQL block", but transactions are connected to a session and not a block.</b> In addition, many players offers scenarios in which the SET TRANSACTION was not the first statement in the block. Great points, but they do not mean that the choice should be marked as correct. This choice can only be correct if I can put the SET TRANSACTION READ ONLY anywhere in my block no matter where my SQL statements are and still have a valid read-only transaction. This is clearly NOT TRUE. If I put SET TRANSACTION READ ONLY after an update statement, Oracle will raise an error when I try to execute the block. So this very broad claim of "can appear anywhere" is clearly false.<br /><br />In fact, now that I think about it, I don't even say "can appear anywhere in the execution section of the PL/SQL block," so this choice can easily be rejected as correct, since you certainly can't put the statement in the declaration section of the block.<br /><br />To conclude: I don't see any way to justify marking this choice as correct. And I did not. It is incorrect. There is no reason for me to change the way I scored this quiz<br /><br />There were many comments in this thread; it is late (12:30 AM) and I am exhausted from a full day of training (and waking up at 4 AM yesterday). So I may have missed something. Please let me know me if you made a comment that you think is left unaddressed.<br /><br />Warm regards, StevenSteven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-17456592202642858842010-10-27T23:15:26.861+01:002010-10-27T23:15:26.861+01:00I believe the phrase 'location' was ambigu...I believe the phrase 'location' was ambiguous and should be fixed in the quiz history. There are some PL/SQL constructs where the 'location' of a statement is restricted (eg a PIPE ROW can only appear in the body of the relevant function) but apart from those circumstances the execution sequence can be independent of the physical sequence of statements in a block (especially with local procedures in the define block). Indeed, there's nothing there indicating whether the <br /><br />Thinking harder after the results, I also came up with the scenario when you code a procedure with a SET TRANSACTION READ ONLY and an exception handler as a test to determine whether the session is currently in a transaction. As pseudo-code this might be :<br /><br />BEGIN<br /> other_pkg.other_proc;<br /> BEGIN<br /> SET TRANSACTION READ ONLY;<br /> EXCEPTION<br /> WHEN OTHERS THEN <br /> RAISE_APPLICATION_ERROR(-20001,'You must explicitly commit or rollback your change');<br /> END;<br />END;<br /><br />I'd prefer to use DBMS_TRANSACTION.LOCAL_TRANSACTION_ID for this sort of test, but the SET TRANSACTION approach would work. <br /><br />So ideally, I'd like to see the question rephrased in the historical log so that it is phrased in lines with "The SET TRANSACTION READ ONLY statement can be successfully executed regardless of any preceding SQL statements in the transaction." The use of 'block' seems to be trying to put a PL/SQL 'spin' on a purely transactional phenomena.SydOraclehttps://www.blogger.com/profile/08828771074492585943noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-15720738158788292092010-10-27T22:16:22.852+01:002010-10-27T22:16:22.852+01:00I didn't participate in yesterday's quiz b...I didn't participate in yesterday's quiz but if I had I probably would have marked it as CORRECT.<br /><br />Why? Because, to make it not work, you have to assume extra steps not stated in the question to make it incorrect. This violates the rules and an ongoing theme of previous objections. <br /><br />For those arguing about the general idea of the question and that it's "obvious" it must be at the beginning of a transaction. Who says the procedure must called at the beginning of a transaction? If the SET is the first line of the procedure that doesn't necessarily make it functional. But, even this shouldn't be taken as a counter argument for INCORRECT, because I'm imposing restrictions outside the scope of the question itselfSeanhttps://www.blogger.com/profile/15790298349995376048noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-84475581059029199312010-10-27T21:26:10.663+01:002010-10-27T21:26:10.663+01:00Let's not split hairs here. I think it is a f...Let's not split hairs here. I think it is a fair assumption that "appear" equates to compile and execute.alchttps://www.blogger.com/profile/05372973618706697631noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-71689783525352049882010-10-27T20:35:25.443+01:002010-10-27T20:35:25.443+01:00Hello All,
The last comment of Karsten just put it...Hello All,<br />The last comment of Karsten just put it right,<br />transaction boundaries and pl/sql block boundaries are completely distinct things,<br /><br />The topic of this question was a little bit<br />"forced" into being a PL/SQL topic.<br /><br />The READ ONLY transactions are a purely SQL <br />notion (except, well, the case of an autonomous transaction that only exists under the "auspices" of a PL/SQL program unit).<br /><br />But my feeling is that the basic intention of Steven was here to check whether we are aware<br />of the need to place SET TRANSACTION to be the first in its transaction, regardless of any PL/SQL block structure, maybe the most characteristic feature of a READ ONLY transaction.<br />Yes, the wording of the choice was maybe not the "happiest" one to carry this intention.<br /><br />I even remember that back in Oracle 6 you could not even execute a SELECT before this statement, so, if ANY DML was executed at all<br />in a session, then a COMMIT or ROLLBACK<br />was required before the SET TRANSACTION.<br /><br />On the other hand, strictly logically speaking, the sentence of this choice, just like any other afirmative sentence expressing a rule or a theorem may be interpreted like this: a rule is true if there is NO single exception possible to it. With this interpretation, it is obvious that the number of counter-examples (pl/sql blocks) that make this sentence FALSE is endless.<br /><br />So, again, an ambiguous question, in which both possible answers can be credited with <br />a certain amount/part of the truth.<br /><br />... Do we still consider computer science a precise science ???<br /><br />Best Regards to All,<br />Iudith Mentzeliudithhttps://www.blogger.com/profile/04905902445036068357noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-32249457888441321992010-10-27T19:14:35.790+01:002010-10-27T19:14:35.790+01:00To answer Riaz's question, the following will ...To answer Riaz's question, the following will fail:<br /><br />declare <br /> a number; <br />begin <br /> commit;<br /> select 1 into a from dual for update; <br /> execute immediate 'SET TRANSACTION read only'; <br /> select 1 into a from dual; <br />end; <br /><br />The "for update" starts a transaction and the SET READ ONLY must be the first statement in a transaction.<br /><br />I thought that any select would start a transaction but that doesn't seem to be the case. Maybe that was true in older versions of Oracle.Anonymoushttps://www.blogger.com/profile/15087906169619255328noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-16361872291627414792010-10-27T17:41:19.068+01:002010-10-27T17:41:19.068+01:00Hi, i believe the marking is wrong.
set transacti...Hi, i believe the marking is wrong.<br /> set transaction needs to be the first statement in a transaction, however, transaction boundaries have nothing to do at all with block boundaries.<br /><br /> Even if set transcation was the first statement in a block, it can still fail if there is an uncommited pending transaction, as others have noted.<br />KarstenUnknownhttps://www.blogger.com/profile/00464276296253932401noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-70614704462230192912010-10-27T17:08:46.018+01:002010-10-27T17:08:46.018+01:00The objection has merit. The requirement is that &...The objection has merit. The requirement is that "SET TRANSACTION READ ONLY" must be the first statement in a read-only transaction; there are no requirements specific to location within a PL/SQL block. A PL/SQL block could have more than one transaction, some of which might not be read-only. It is also possible that multiple read-only transactions could appear within the same block which would require multiple "SET TRANSACTION READ ONLY" statements. It is even possible that a PL/SQL block might have no queries and yet still include "SET TRANSACTION READ ONLY" (in fact, it is possible for that to be the only statement within the block since the scope is a transaction not a block). Perhaps none of these cases have practical merit, but all are technically valid and none are excluded by the wording of the quiz or choice.<br /><br />Although the intent of the "location" choice seems to have been clear to most players, that intent is not clearly expressed in its wording. Had the phrase been "regardless of the locations <i>or types</i> of SQL statements in that block" then the choice would have been unambiguously incorrect. Some have stated that the meaning of the choice should have been discernable from the focus of the other choices; however, that argument is invalid because the list of assumptions includes the following:<br /><br />"You should not assume there is any kind of relationship between the multiple choice answers. Specifically, information in one choice does not have any bearing on the correctness of another choice."<br /><br />Players who correctly inferred the intent of the choice should keep their scores; those who responded based on a literal interpretation should be given credit.jhall62https://www.blogger.com/profile/10339038131928463003noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-74345768836612174372010-10-27T12:24:54.245+01:002010-10-27T12:24:54.245+01:00Hi Steven, I have an objection to the tuesday, 26t...Hi Steven, I have an objection to the tuesday, 26th October Quiz: <br /><br />I think that the answer is correct, too - but for different reasons:<br /><br />SET TRANSACTION don't have to be the first statement. <br />The SQL Statements can be anywhere located in your BLOCK, as long as all transactions are closed before the SET TRANSACTION. <br />Look at this: <br /><br />DROP TABLE plch_parts purge<br />/<br /><br />CREATE TABLE plch_parts<br />(<br /> partnum INTEGER<br /> , partname VARCHAR2 (100)<br />)<br />/<br /><br />BEGIN<br /> INSERT INTO plch_parts<br /> VALUES (1, 'Mouse');<br /><br /> INSERT INTO plch_parts<br /> VALUES (100, 'Keyboard');<br /><br /> INSERT INTO plch_parts<br /> VALUES (500, 'Monitor');<br /><br /> COMMIT;<br />END;<br />/<br /><br /><br /><br />declare<br /> vx varchar2(10);<br />begin<br /> SELECT dummy<br /> into vx<br /> from dual;<br /> UPDATE plch_parts set partname = upper(partname);<br /> ROLLBACK;<br /> SET TRANSACTION READ ONLY;<br /> select partname<br /> into vx<br /> from plch_parts<br /> where partnum=100;<br />end;<br />/<br /><br />Regards<br /><br />RobertUnknownhttps://www.blogger.com/profile/12886240178851048695noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-59838639461252014822010-10-27T12:10:49.250+01:002010-10-27T12:10:49.250+01:00Ahh, come on, we're programmers, not attorneys...Ahh, come on, we're programmers, not attorneys. You don't really want a several pages fine print of assumptions and questions stated in an unbreakable form, but awfully hard to understand. <br />Obviously compilable is not sufficient, it needs to be executable as well.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-72103515095852314352010-10-27T12:04:49.756+01:002010-10-27T12:04:49.756+01:00The question is about "read only transactions...The question is about "read only transactions" not the "set transaction" statement. Therefore to have a read only transaction the "set transaction" statement MUST come first. Qouting from doc "Establishes the current transaction as read-only, so that SUBSEQUENT [caps mine] queries .."<br /><br />I think Steven is right on this one. But, I say that because I had a red flag waving around the "statement" in question but put on my uber-literal hat and got the correct answers.Sparkyhttps://www.blogger.com/profile/11199100397673558515noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-81781319628341635152010-10-27T11:55:57.342+01:002010-10-27T11:55:57.342+01:00Steven,
I agree with you on this one. The choice i...Steven,<br />I agree with you on this one. The choice is incorrect.<br />I got it wrong because I also at first thought that it doesn't matter where you put SET TRANSACTION READ ONLY in the context of PL/SQL block, but when I think about it in the context of a transaction (and we can have more than one transaction in a block) it does matter where we put it - we have to put it before any SQL statement in that transaction.<br /><br />Dalibor KovačDalibor Kovačhttps://www.blogger.com/profile/02433329562766532176noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-65789225276836340742010-10-27T11:27:24.545+01:002010-10-27T11:27:24.545+01:00Hi Steven,
I knew this part of the question would ...Hi Steven,<br />I knew this part of the question would become a troublemaker. Instantly after submitting my answer, I thought "hopefully this is not getting another language proficiency issue"...<br />It is clear that the SET TRANSACTION READ ONLY statement has to be the first in the sequence of statements comprising the transaction. Anyway, I regard the objection you've quoted as valid.<br />Furthermore, if you construct a case where only SELECTS are used, the location of the statements indeed doesn't matter, e.g.: <br /><br />DECLARE<br /> x NUMBER;<br />BEGIN<br /> SELECT 1 INTO x FROM DUAL;<br /> SET TRANSACTION READ ONLY;<br /> SELECT 2 INTO x FROM DUAL;<br />END;<br />/<br /><br />works fine without throwing ORA-01453.<br />So - yes, "SQL" does imply DML and then it matters where SET TRANSACTION is located. Which means you are right. Nevertheless, I still see a bit of ambiguity in this answer.<br /><br />Anyway, I've learnt something from this quiz, and that is what counts for me!<br /><br />Best regards,<br />UweUwe Küchlerhttps://www.blogger.com/profile/08199596117280621443noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-69935009228928478102010-10-27T10:20:18.290+01:002010-10-27T10:20:18.290+01:00I think this is just another playing with words. O...I think this is just another playing with words. On the other hand I agree that to make the choice bulletproof it should say "to execute without error".<br /><br />My comment is not very helpful, is it?<br />Well, in construction of the question and the choice I think it should be marked as correct.<br /><br />Regards<br />LudoUnknownhttps://www.blogger.com/profile/03813440070210845954noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-22104499406134440662010-10-27T10:19:29.822+01:002010-10-27T10:19:29.822+01:00Hello,
The objection seems to be not justified en...Hello,<br /><br />The objection seems to be not justified enough for 2 reasons:<br />- all other choices clearly deal with the execution, not the compilation thus defining the "question context"<br />- "can appear anywhere in your PL/SQL block" definitely includes anonymous blocks for which execution and separation cannot be separated. That means that any attempt to use an anonymous block with the misplaced SET TRANSACTION will fail. <br /><br />For these reasons the choice in question was properly deemed as incorrect.al0https://www.blogger.com/profile/15743792964167204705noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-53607910896562119602010-10-27T09:52:31.725+01:002010-10-27T09:52:31.725+01:00The question is about behavior inside a program un...The question is about behavior inside a program unit. To answer such a question, it is a fair assumption that the code compiles, I think.<br /><br />MikeMikehttps://www.blogger.com/profile/04855911908563127732noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-79730021190331370342010-10-27T08:47:17.289+01:002010-10-27T08:47:17.289+01:00This comment has been removed by the author.Christian Rokitta ♠https://www.blogger.com/profile/07809391154664980631noreply@blogger.com