tag:blogger.com,1999:blog-8677649049588007585.post5655385398602316526..comments2023-06-18T16:15:22.432+01:00Comments on PL/SQL Challenge: Feedback on "Unnecessary Code" Quiz Rules, PleaseSteven Feuersteinhttp://www.blogger.com/profile/16619706770920320550noreply@blogger.comBlogger66125tag:blogger.com,1999:blog-8677649049588007585.post-31784374850153342322013-03-15T17:54:49.049+00:002013-03-15T17:54:49.049+00:00And I will add that resource to the quiz topic.And I will add that resource to the quiz topic.Steven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-69289649970555454232013-03-15T17:54:27.902+00:002013-03-15T17:54:27.902+00:00The Oracle PL/SQL User Guide defines "delimit...The Oracle PL/SQL User Guide defines "delimiter" for us:<br /><br />http://docs.oracle.com/cd/E11882_01/appdev.112/e25519/fundamentals.htm#CHDJAFIFSteven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-64153868097376929242013-03-15T17:51:46.663+00:002013-03-15T17:51:46.663+00:00Hello Steven,
Now it comes to define precisely &q...Hello Steven,<br /><br />Now it comes to define precisely "delimiter" as well <br /><br />In some contexts, an "underscore" is also considered a delimiter.<br />For example in functions like INITCAP, any non-alphanumeric character is a delimiter.<br /><br />But in our set of rules I guess it is NOT, at least as the example of PLS_INTEGER shows.<br /><br />Thanks a lot & Best Regards,<br />Iudith<br />iudithhttps://www.blogger.com/profile/04905902445036068357noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-75436882796794695702013-03-15T17:13:54.834+00:002013-03-15T17:13:54.834+00:00I will add a definition of word ("text separa...I will add a definition of word ("text separated by delimiter or whitespace") to the rules.<br /><br />Yes, I think that you can remove a, b, and c according to the rules.<br /><br />And according to my rules, you certainly could remove WITH, LOCAL, TIME or ZONE from that type declaration. The result may not be valid code and therefore will not be <i>correct</i>, but it would be a valid removal.Steven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-58263923611620682752013-03-15T17:01:52.671+00:002013-03-15T17:01:52.671+00:00Hello Steven, All,
A case that I think was not di...Hello Steven, All,<br /><br />A case that I think was not discussed up to here:<br /><br />If a variable is defined as NUMBER(m,n) , then is the removal of any of the following:<br /><br />a. (m,n)<br />b. m,<br />c. ,n<br /><br />allowed ?<br /><br />Well ... some coders may even put a blank in between, like in "NUMBER (m,n)" ,<br />so the precision/scale element can even be a "separate word" .<br /><br />As by how I understand the rules, I guess that such a removal is allowed.<br /><br />Also, the example with "TIMESTAMP" in the rules list should be corrected,<br />you cannot remove ZONE only, just eventually LOCAL from "TIMESTAMP WITH LOCAL TIME ZONE",<br />or ALL the words except TIMESTAMP itself.<br /><br />And, also, eventual precision if specified, similarly as for the NUMBER case above.<br /><br />Thanks & Best Regards,<br />Iudith<br /><br />iudithhttps://www.blogger.com/profile/04905902445036068357noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-63552387562394105362013-03-14T21:29:00.671+00:002013-03-14T21:29:00.671+00:00Thanks, I will fix that typo. I don't plan to ...Thanks, I will fix that typo. I don't plan to show invalid code, so that won't be a worry.Steven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-5923821053628729452013-03-14T21:01:50.580+00:002013-03-14T21:01:50.580+00:00>>> Removal of a part of an delimiter
&q...>>> Removal of a part of an delimiter<br /><br />"a" instead of "an"<br /><br /><br />This probably won't apply, but what if the existing code is invalid. What does removing code from a syntax error do to the results? I suppose it could change the compilation error, but does that count as necessary?<br /><br />What about invalid code where I remove something and it still fails with the same error? Is that unnecessary?<br />Seanhttps://www.blogger.com/profile/15790298349995376048noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-35428891014984979612013-03-14T19:26:07.771+00:002013-03-14T19:26:07.771+00:00The final set of rules are those you see at the to...The final set of rules are those you see at the top of this thread (original post). I updated them as I accepted suggestions for changes.<br /><br />Yes, I suppose I have given everyone advance notice of the "topic" for that quiz - but it's such a general topic, I don't think it will help anyone...do you?Steven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-12141048775577952962013-03-14T19:22:39.616+00:002013-03-14T19:22:39.616+00:00Hello Steven,
Is that something new ? ( I don&#...Hello Steven,<br /><br />Is that something new ? ( I don't want do deal with whether this is good news or bad news ... )<br /><br />Usually a quiz topic is *not* published ahead of time ... for good and for worse ...<br /><br />If this is the case, a revision of the finally (actually ?) adopted set of rules will be a good service for everybody, <br />I personally find it difficult enough "to screen them out" from this stuffy pros-and-cons looooong thread ...<br /><br />Thanks a lot & Best Regards,<br />Iudithiudithhttps://www.blogger.com/profile/04905902445036068357noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-68986974380597200972013-03-14T15:39:24.500+00:002013-03-14T15:39:24.500+00:00Right! Thanks to everyone who contributed, especia...Right! Thanks to everyone who contributed, especially Sean and Iudith - for your ideas, patience and passion. :-) <br /><br />I feel at this time that I have a set of rules I can use and also an excellent idea from Sean to take the opposite approach and define limited rules relevant for each quiz. So it it is a fine time to end this discussion.<br /><br />I will offer another "unnecessary code" quiz next week, based on the rule set. The rules will be available BEFORE you play on the "launch" page. So players will not have to pay with quiz time to read through the text.<br /><br />We'll see how that goes....Steven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-53555006815771785392013-03-14T12:36:00.844+00:002013-03-14T12:36:00.844+00:00Hello Sean,
You are right, probably our positions...Hello Sean,<br /><br />You are right, probably our positions seem to be irreconcilable at this moment,<br />though, interestingly enough, my impression was all the way that you are the one who favorizes the content<br />aspect (resource consumption), having stated it as the reason for which you considered<br />the EXECUTE IMMEDIATE removal to be allowed.<br /><br />I agree with you that rules are topmost important, but I won't like to arrive to the point where<br />the rules will become the central points of the quizzes.<br /><br />If "word wizardry" starts to be allowed, then we will find ourselves just amending/extending the rules all the time<br />for covering all the upcoming different "clever exploits" of any quiz, by those who might happen <br />"to overthink the authors" in one case or another... as it happened with this first quiz and some other ones<br />in the past.<br /><br />There is no "official" set of rules for such a topic, we will have to invent our own set, <br />and, while a set might seem to be comprehensive, clear, and closed, it is just a matter of time when some specific quiz will arrive and prove that this was not the case.<br /><br />The problem with the March 1 quiz was not whether the author did or did not think about performance implications of the code removals, it was clear from the quiz that all what did matter was ONLY the result/outcome.<br /><br />What was not so clear was what is a "legal code removal" ... and here is where this discussion started<br />and it still lasts for about two weeks ... though, probably, all the other participants have decided<br />to retire from it because it will probably never arrive to an equally satisfactory end for everyone.<br /><br /><br />Thanks & Best Regards,<br />Iudith<br /><br />iudithhttps://www.blogger.com/profile/04905902445036068357noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-8545698390660383862013-03-14T03:40:48.302+00:002013-03-14T03:40:48.302+00:00There is no added value in making the "entire...There is no added value in making the "entire entities" restriction than in allowing anything to be removed. It's just preference.<br />However, the cost of making that restriction is complicated and arcane rules wording.<br /><br />As for "constructive knowledge" I've already given up on that argument. Changing the code in anyway that alters the performance (more/less memory, more/less latches, more/less io, more/less cpu, more/less time, etc.) is extremely important but has already been thrown out as part of the scope of these types of quizzes. I think that diminishes the quizzes, but so what? As long as the quiz intent is clear and verifiable it's a good quiz. These quizzes, like all others, are about whether you can identify the significance of various forms of syntax. You can call them "cosmetic" if you want, and, if you ignore performance ramifications, a lot of the changes could be considered cosmetic only; but again... so what?<br /><br />Removal is an interesting twist on syntax identification; but it rings false to apply some special consideration that we could remove some syntax but we're going to arbitrarily not allow you do so.<br />Plus, and this is very important, by using a simple rule. It frees the question authors to make more types of questions. With a complex rule, they are just as bound by tricks of word wizardry in forming the questions to make sure they are really asking.<br /><br />The execute immediate example that everyone seems to carry on about is silly. The snippet has bad code, my suggestion was remove the bad part and you'll get the same results. To me that was obvious but I didn't know if performance was supposed to be part of the results. So in the end, I simply guessed. The ramifications of the change (performance and output) were obvious to me but I couldn't say for sure what the author was going to consider. That's a bad quiz.<br /><br />Since the rules have now been clarified (simplified) that performance doesn't matter, I don't like it; but who cares? Neither you nor I have to "like" a question, we simply have to agree that what is asked and what is answered are easily identifiable.<br /><br />I don't want to win this argument because I've convinced anyone the questions will have better content (although I think they might.) I want to win this argument because I've convinced everyone (or at least Steven) that removing ambiguity and confusion is paramount. When there is no confusion, there is no argument, or at least no reasonable argument.<br /><br />>>> they are counter-educative and of no real value, except for avoiding such post-quiz discussions ...<br /><br />You're ascribing deficiencies to questions that haven't even been created yet. I trust the quiz authors, including you, can create helpful quizzes with simple, clear rules.<br /><br />I don't really expect to avoid post-quiz discussions, rather to make them short and to the point. Whether correcting a player that got it wrong, or highlighting something that everyone else missed, the discussion becomes simply: run the code, verify results, score accordingly.<br /><br />I think you and I are probably at an impasse. I value clarity of the questions over the actual content of the questions. You put the content higher.<br />So our arguments don't really appeal to each other and, in fact, probably don't even make sense to the other.<br /><br />For example, I've done network ACL configuration more often than I've written code with varrays. So, if you ask me a question about varray I'll probably learn more than if you ask me one about how conflicting and complimentary ACLs resolve.<br /><br />Since the author can't know who will know what; the only universal aspect is the clarity of quiz text and rules for answering it.<br /><br />I think I've said the same thing at least 5 times now; so I've probably used up my quota of repetition. In the spirit of the thread, I'll remove myself now as further repetition will be unnecessary. Seanhttps://www.blogger.com/profile/15790298349995376048noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-86929855752178458152013-03-13T19:00:53.633+00:002013-03-13T19:00:53.633+00:00Hello Sean, All,
If we go back to the quiz of Mar...Hello Sean, All,<br /><br />If we go back to the quiz of March 1, the introduction to that quiz presented this example:<br /><br />BEGIN<br /> NULL;<br /> DBMS_OUTPUT.PUT_LINE (1);<br />END;<br /><br />and suggested that NULL; is an example of unnecessary code.<br /><br />From here, probably most straight-forward thinking players (and I really mention here straight-forwardness <br />as a positive quality of a good developer !) were automatically driven to consider "code" as being the same as<br />"statement", or, at most, maybe an entire variable declaration line.<br /><br />In this light, EXECUTE IMMEDIATE was NOT "code" (aka statement !) that could be removed, <br />but just text, that happened to be followed by a particular string ...<br /><br />Therefore, I strongly believe that we should still stick to only allow removing entire entities <br />and not just performing "cosmetic text changes" that happen to leave the result in place,<br />like the SUBSTR in Niels' example in one of the previous posts ...<br /><br />Also, I strongly disagree that everything that leaves the result in place should be removed !!!<br />EVEN if it is possible to create an artificial set of rules that will cover such cases,<br />they are counter-educative and of no real value, except for avoiding such post-quiz discussions ...<br /><br />Of course, it requires some attention to figure out whether a result remains the same if we remove<br />just some part of an identifier or part of a data type name ... but I would not go for calling this <br />PL/SQL knowledge, and it is NOT a good method to educate the players in the direction of constructive development ...<br /><br />So, if you don't like the simple term of "knowledge" whose usage is so imperiously demanded<br />by each post in this thread, then let's call it "constructive knowledge", in opposition with just<br />"word juggling capacity".<br /><br />I dare say that pretty all the players that answered that 4-th choice differently from what you have considered,<br />did so not because they don't know that a static INSERT has the same effect as a dynamic one ...<br />but because they did NOT consider that removing part of a statement is in accord with the<br />let's name it, not so precise rules.<br /><br />It is very frustrating to be punished for having violated a "rule" that you did not know about !!!<br />Or, better say, one that you have misinterpreted or, more precisely, you have interpreted <br />exactly the same as the authors and reviewers did by themselves, before the debate started and other<br />possible interpretations were suggested ...<br /><br /><br />Thanks & Best Regards,<br />Iudith<br />iudithhttps://www.blogger.com/profile/04905902445036068357noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-65616643748546424612013-03-13T15:09:33.968+00:002013-03-13T15:09:33.968+00:00I'm not angry, but I am confused as to how the...I'm not angry, but I am confused as to how the debate can still be going.<br /><br />>>>without any implication of any knowledge ...<br /><br />I disagree with this, it takes knowledge to figure out what can or cannot be removed and still produce the same results. That seems obvious to me, but maybe I'm missing the point of that statement.<br /><br /><br />>>> we are just sinking and sinking deeper into "word puzzles" instead of focusing on PL/SQL knowledge.<br /><br />That's exactly my point in wanting simple rules. If you have to think "is this an exception?" "I could remove abc, but will it be counted?" Then the rules are too complex and the quiz is about rule parsing and not code parsing. <br /><br />Simple rule: If you can remove it and the output doesn't change, then it's not necessary. It might be good practice, it might be bad practice, it might be philosophically completely different, but it's not necessary.<br /><br /><br />If the author wants to test knowledge of a particular pl/sql feature. Then put that into the quiz. All of the disputed removals in the first quiz could have been avoided simply by writing the code examples a little differently.<br /><br />It seems the counter arguments to simple rules are based on personal preference of what types of knowledge are considered valuable. <br /><br />I definitely disagree that removing execute immediate and the corresponding quotes was simply a word-puzzle. It required pl/sql knowledge to know that removal would have no impact on the results. Was it sophisticated knowledge? No, but then again, none of the intended or unintended removals were particularly complicated.<br /><br />That fact that some players didn't think of some of the removals doesn't invalidate the fact that the removals were legal. Furthermore, if some players did notice the removals and then decided to dismiss them as not important - that personal preference is the error, not the rules and not the quiz. <br /><br />As I mentioned before, I find it distasteful to mark bad code as "correct". However, that's a personal preference too. If the bad code generates the expected output of the quiz, then it's "correct" by those rules.<br /><br />It's definitely playing games with the rules to say an answer was technically correct but shouldn't have scored that way. Being correct about easily verifiable code is not an "exploit", it's simply being correct.<br /><br />I'll say it again because it's the core of my argument and I have yet to read a counter to it.<br /><br />Simple rule: if you can remove it and the output doesn't change, then it's not necessary. It might be good practice, it might be bad practice, it might be philosophically completely different, but it's not necessary.<br /><br />Seanhttps://www.blogger.com/profile/15790298349995376048noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-17656602025243330602013-03-13T12:18:05.577+00:002013-03-13T12:18:05.577+00:00>>> I worry about our many non-English-sp...>>> I worry about our many non-English-speaking players having to work through all that verbiage.<br /><br />I definitely agree there.<br /><br />We had plenty of Only-English speakers that also thought what we started with was confusing. <br />Make the rules simple, put the complexity in the quiz. Not the other way around.<br /><br />As long as the results can be unambiguously verified, personal preference (even of the author) of what should or should not have been included are irrelevant.<br /><br />Code X produces output Y. Can I remove non-white space text from X and still get Y? Yes or No?<br /><br />That seems bulletproof to me. Simple is better. Any dissenters want to poke a hole in it?Seanhttps://www.blogger.com/profile/15790298349995376048noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-11744518379745510312013-03-13T08:33:18.718+00:002013-03-13T08:33:18.718+00:00Hello Steven, All,
Looks like after some progress...Hello Steven, All,<br /><br />Looks like after some progress in the direction of favoring common sense and prevailing of PL/SQL features,<br />we again drop back to simply trying to wipe out text to make the code lines shorter, without any implication<br />of any knowledge ...<br /><br />Again, shortening identifiers to one single letter and changing data types to those whose names are shorter<br />is what we are really after in these quizzes ?!?<br /><br />That would be very sad and disappointing ...<br /><br />I think that the removal should be limited to what indeed is removable based on PL/SQL (and in fact, Oracle)<br />behavior, as was the intention of the authors and reviewers for the quiz of March 1 ...<br /><br />Since then, following Sean's exploiting of that poor dynamic SQL statement ...<br />we are just sinking and sinking deeper into "word puzzles" instead of focusing on PL/SQL knowledge.<br /><br />I agree that a stuffy and verbose set of rules will not ease the life of any players, not just of those who are<br />non-native English speakers, but, above all, it will make a tremendous anti-service to the PL/SQL knowledge itself, which should remain the focus point of this competition.<br /><br />Instead of rigid rules, we are maybe just one step away from rather formulating "rigid quizzes",<br />aka, quizzes that specify exactly the line numbers where removal is allowed.<br /><br /><br />Hope that no one will feel angry for my remarks, I cannot but be as sincere as always.<br /><br />Thanks a lot & Best Regards,<br />Iudith<br />iudithhttps://www.blogger.com/profile/04905902445036068357noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-90359320128729084092013-03-13T02:20:36.193+00:002013-03-13T02:20:36.193+00:00Thanks, Sean. Your idea makes an awful lot of sens...Thanks, Sean. Your idea makes an awful lot of sense. On the one hand, after all this effort at crafting consistent rules (which I believe at this point has been achieved successfully), I hate to give it up. On the other hand, I worry about our many non-English-speaking players having to work through all that verbiage.Steven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-47072835199743705482013-03-12T19:51:34.084+00:002013-03-12T19:51:34.084+00:00Rather than trying to get super precise wording th...Rather than trying to get super precise wording that prevents clever parsing. Wouldn't it be simpler to just open it up and then construct questions with or without the conditions.<br /><br />Which of the code examples below have any text except white space that could be removed and produce the same output.<br /><br />Then, simply use single character variables and INT instead of PLS_INTEGER and VARCHAR instead of VARCHAR2.<br /><br />Or, if you want to lose styling preferences then leave the general rule in place but list explicit exclusions.<br /><br />With the following exceptions that may not be altered in anyway:<br />l_my_int<br />l_my_string<br /><br />Which of the code examples below have any text except white space that could be removed and produce the same output.<br /><br /><br />If you want PLS_INTEGER limits to be in effect, then arrange the question so you'll run into those limits.<br /><br />If you don't want dynamic sql to be converted to static, then write sql statements that are actually dynamic.<br />It seems wrong to me to disallow conversion of static sql to static sql simply because the original sql was forced through unnecessary dynamic execution (especially in a quiz about unnecessary code detection.)<br /><br />Anytime an author is creating an "unnecessary code" quiz, he or she is probably checking to see if the players will notice a particular feature or set of features. So... code for that those particular features.<br /><br />If by chance something slip through and extra code is detected by player, then change the scoring for everyone to reflect the correct answer. If the question text is unambiguous that ANYTHING except white space and the ONLY criteria for acceptance is if the output matches some stated text. Then it will be easy after-the-fact to confirm the results and score accordingly. If the scoring wasn't what was intended, so be it. <br /><br /><br /><br />Seanhttps://www.blogger.com/profile/15790298349995376048noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-34990635821686829572013-03-12T19:25:07.688+00:002013-03-12T19:25:07.688+00:00Hello Steven, All,
Looks to me that this thread b...Hello Steven, All,<br /><br />Looks to me that this thread becomes more and more difficult to follow ...<br /><br />In the example above, it is NOT the word "ZONE" from "TIMESTAMP WITH TIME ZONE" that can be removed,<br />but the word "LOCAL" from "TIMESTAMP WITH LOCAL TIME ZONE" ... or ... well ...<br />if you wish, to remove ALL the words and leave only "TIMESTAMP" alone .<br /><br />Anyway, I still think that this is a data type name, even if composed of several words, which is pretty unusual,<br />in other similar cases there used to be an underscore between the component words.<br /><br />I don't think that here each component word can be considered as a separate identifier, <br />so, though the standard definition of an identifier does not allow for embedded blanks without surrounding<br />the entire identifier with double quotes, however, I think that data type names should still be considered<br />similar to the other identifiers, aka, no partial removal allowed.<br /><br />Objections will follow anyway, I am pretty sure about it ...<br /><br />However, I don't think that losing sensibility is the best way to go, <br />in life in general, and among friends especially.<br /><br />Thanks a lot & Best Regards,<br />Iudith<br />iudithhttps://www.blogger.com/profile/04905902445036068357noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-68304821129502113702013-03-12T13:48:50.379+00:002013-03-12T13:48:50.379+00:00That's precisely it, Brigt. According to the o...That's precisely it, Brigt. According to the original (vague) rules), it WAS allowed to switch from dynamic to static in that way. It will be no longer acceptable. Steven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-90830356907124428562013-03-12T12:59:56.855+00:002013-03-12T12:59:56.855+00:00Yes, I do (still) agree that it is logically sound...Yes, I do (still) agree that it is logically sound - merely prone to misunderstanding, as evidenced by your own initial stance that it was allowed.<br /><br />Or, maybe I am confused and the no-partial-literal-removal rule wasn't part of the rules to begin with? I thought it was, and that it was Niels explaining the ramifications which convinced you that it could not be allowed after all.<br /><br />Anyway, for myself things are clear, so I guess I'll drop this discussion and reap the benefit of others' potential misunderstanding =).Brigt Viknoreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-85862404124693192662013-03-12T11:21:29.261+00:002013-03-12T11:21:29.261+00:00Brigt, the reason I say that now it is clear from ...Brigt, the reason I say that now it is clear from the rules that a switch from dynamic to static would not be allowed is that we do not allow parts of literals to be removed and I offer as an explicit example that "you cannot remove single quotes from around a literal string".<br /><br />Doesn't this cover the dynamic->static switch, at least in the form that came up in the first quiz? Why Steven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-65568698308836957052013-03-12T11:09:00.560+00:002013-03-12T11:09:00.560+00:00Steven, you should be aware that the rules text, w...Steven, you should be aware that the rules text, without the corollary comments, is prone to misunderstanding - for a prime example of this, see your own comment from 05 March, 2013 11:53. You say there the rules CLEARLY allow changing from dynamic to static SQL. And yet, now you think they sufficiently clearly disallow it?<br /><br />I do agree that it is logically sound that the rules preclude changing to static SQL and changing the rules text is therefore not strictly necessary. Still, I would prefer a bit of embellishment for clarity.<br /><br />As an aside, I think you misread me a bit. I tend to complain when I disagree, and am aware of my argumentative nature - which is what I was talking about when saying I will only occasionally abide by rules without complaint.Brigt Viknoreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-50034055930499740532013-03-12T01:28:10.277+00:002013-03-12T01:28:10.277+00:00At first, I was going to write "I am happy to...At first, I was going to write "I am happy to emphasize in the example that the switch to static from dynamic SQL is not allowed."<br /><br />But then I considered the critical issue of data normalization.<br /><br />My "users" are supposed to be highly trained logicians, masquerading as programmers. They should be able to think abstractly, applying general rules to specific situations.<br /><br />So I think that as long as the rule makes the switch from dynamic to static invalid, that will have to be sufficient.<br /><br />And thanks, Brigt, for your willingness to play without complaint, though I hope you never hold back for the sake of my delicate sensibilities.<br /><br />I lost them somewhere, a long time ago. There do not seem to be any lingering sensibilities.<br /><br />SFSteven Feuersteinhttps://www.blogger.com/profile/16619706770920320550noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-55163308873754518332013-03-11T23:06:40.537+00:002013-03-11T23:06:40.537+00:00"Brigt, going from dynamic to static is certa..."Brigt, going from dynamic to static is certainly a change to the code, just not a change according to the rules of this quiz. Do you feel that it is not clear or that this is just TOO WRONG and should not be allowed? :-)"<br /><br />I thought it was not sufficiently made clear in the rules you initially laid out - I will abide by any clear set of rules (and in some cases will even do so without complaint ;)).<br /><br />I still think that the clarification in the comments that the "must remove entire literal" rule prevents changing dynamic to static SQL can still be more clearly specified in the text of the ruleset (my addition within the asterisks: "Another example: you cannot remove single quotes from around a literal string*, such as dynamic SQL*.". Although I suppose that could be considered "unnecessary text" =).Brigt Viknoreply@blogger.com