04 September 2010

Players cry "No choices right!" for 3 September quiz(1370)

The 3 September quiz regarding use of the RAISE; statement includes this paragraph: Each of the choices below contain code to create a procedure named proc2 (and in some cases, another procedure named show_error). After executing the code in each choice, I then want to run the following block and see an unhandled VALUE_ERROR exception ("ORA-06502: PL/SQL: numeric or value error"). Several players wrote to say that none of the choices could be correct because all of them could only display at most the error code, but not the error message, since I called SQLCODE and not SQLERRM. That is true, but what I stated was that I want to "see an unhandled VALUE_ERROR exception." I then included the full message text in parentheses to be clear about how the VALUE_ERROR exception (defined in the STANDARD package) would appear as an unhandled Oracle error. I did not ask "What text will be displayed on the screen?" So I believe that the quiz was scored correctly and no changes will be made. Your thoughts?

Additional "Very Fast Answer" Adjustments Made

You may notice further changes in rankings, though not at the top. I realized today, as I was preparing the next PL/SQL Challenge newsletter, that not everyone whose answers were astonishingly fast had been adjusted. I looked more closely at my algorithm and found that I was restricting the adjustment only to those in the top 10 rankings.

Obviously, that is not appropriate.

So I applied it more broadly and 48 players were bumped down in the rankings.


02 September 2010

Adjustments made, adjustments planned, playoff approaching

I just finished the adjustments for "very fast answers" for the period 15 August to 31 August. You will see some changes in the rankings soon. This is my least favorite part of the PL/SQL Challenge: to have to even imply that maybe some players are violating rules. I hate it, but what else can I do? If your pattern of play is indistinguishable from someone who cheats, I must taken action to protect the credibility of the daily quiz.

So please: take your time, read the questions and choices thoroughly and carefully. Enjoy and learn!

I will also in the coming week to ten days apply the first round of "forgiveness" adjustments - up to 10 missed quizzes and/or 0 scores will be "forgiven" according to an algorithm defined on the Rules page of plsqlchallenge.com.

And then....the second quarter in the history of the PL/SQL Challenge will come to an end, which means we will be holding our second championship playoff in mid-October. So sharpen your pencils and your wits - and do everything you can to boost your score in this last month of the quarter.

Don't be discouraged if your rank is not that high - you can still gain entry into the playoff through a wildcard selection. See the Rules page for more details.

Before we announce participants, we will do another round of adjustments (for very fast answers and forgiveness).

I also expect to upgrade to version 1.6 of PL/SQL Challenge before the playoff, hold a special PL/SQL Challenge competition for Oracle Open World, and lots more!

Soon, soon, soon, you will receive a newsletter will details of the above and much more, so be on the lookout for that.

Steven Feuerstein
"Obsessed with PL/SQL - and what's wrong with that?"

31 August 2010

Massive Confusion by Steven regarding 30 August quiz (1366)

Seeing as I am in Puerto Rico right now, I will blame my lack of clear thought (and the resulting impulsive actions) to Hurricane Earl.. :-) Sigh. Yesterday, I received a report of a mistake in the 30 August quiz and rather than think it through carefully, I too quickly accepted that I had made a mistake (which says something about my personality), went through my re-scoring process, had some problems with that (which several of you have reported), wrote a blog posting on the mistake, rewrote a blog posting and finally went to bed. It rained all night. It is raining today. And also today, several players have now pointed out that the mistake was not a mistake. My original scoring was correct. The choice (which referenced a column of a data dictionary view in a way that ensured the procedure would never compile, regardless of the optimizer level) should have been marked - and stayed marked - as incorrect. In my blog post, I noted that a player had complained about the complexity of the language (and presence of double negatives) in my question text. It tripped him up and, you know what? It made it much more difficult for me to see that I had not, in fact, made a mistake! Very frustrating - for all involved, I am sure (at least if you pay close attention to the quiz results and commentary on them). So I have made a real hash of things for the 30 August quiz. I have already cleaned up the question text, to make it at least a little bit more clear. I will work on that further to see if I can rid of any double negatives. I will then make sure that choices are marked correct only if they are TRULY correct - and make sure the explanations are clear about why. But in the end, given all the confusion, my plan is to STILL give everyone credit for a correct answer on the choice that has caused so much confusion, and then rescore/rerank. It may take a little while to do all this because we lost power at our house, so I am grabbing moments in which to get online. Rest assured that before I award prizes for August, I will resolve all scoring issues with the 30 August quiz, apply the "very fast answers" adjustments and also apply the forgiveness adjustments for the first time. So be patient and keep playing! My apologies for all the confusion. Thanks for sticking with the PL/SQL Challenge as I muddle through. Cheers, Steven Feuerstein

Questions regarding 30 August Quiz and ALL_PLSQL_OBJECT_SETTINGS (1366)

The 30 August quiz asked you to choose options that would stop a program unit from being usable if the optimization level for that unit was < 2 (the current default level of "aggressive" optimization). One choice, scored as correct, was:
  l_level PLS_INTEGER;
  IF l_level < 2
END compute_intensive;
Several players raised a concern about this scoring, with one person writing: "Hello, from my point of view today quiz contains a bug. The third choice should use not only NAME but as well OWNER in the WHERE clause [since it was a query against an ALL* view], otherwise it may fail even if the PLSQL optimization level for it is set to 2 (with TOO_MANY_ROWS). For this reason I have not selected it, while I assume it was intended as the "correct" choice." And as another player put it: "To be pedantically correct, shouldn't it either use USER_PLSQL_OBJECT_SETTINGS or include the OWNER in the where clause? There might be an object with the same name in a different schema that current user has access to (and therefore included in the ALL_* view.) (But if such an object existed, I would get a runtime exception of too many rows, so the answer is still 'correct.' Anyway, the general assumptions of course tells me that there probably is NOT another schema with such an object, so I'm not asking for any rescoring - mostly that when you publish the answers you might make a note that when using ALL_* view it's normally prudent to include OWNER in the where clause." Well, to tell you the truth, that last comment pretty much said it all. To summarize: 1. I should have included "OWNER = USER" in the query against the ALL_PLSQL_OBJECT_SETTINGS view. In fact, any query against an ALL* view should include a predicate in the WHERE clause for the owner - unless you really want to analyze rows across all schemas. 2. There is no need to rescore. As the second player explained, the assumption for the quiz is that the only DB objects that exist are those described in the quiz itself (or defined by Oracle with the installation of the database). So the query could only return one row. 3. I will change the choice to reflect this critique (add "OWNER = USER"). To conclude: no change in scores or ranks, but I will strive in the future to either use a USER* view or include an "OWNER=" predicate with an ALL* view. Thanks for pointing this out! Finally, another player had a very different concern: "The wording of today's quiz was really puzzling for a non-english like me. I'm not sure to have understood what was the question. Don't you think there was a simpler way to write the same sentence?" My apologies; I do see what you mean. I need to step embedding sentences within questions, as I do below: "Which of the choices define a program named "COMPUTE_INTENSIVE" in a way that ensures that the program cannot be used (it will either fail to compile or always raise an exception before the local subprogram body_of_proc is executed) unless the PL/SQL compiler optimization level for the program is set to at least 2?" Thanks for reminding me about this. I will continue to try to simplify the language I use in the questions. SF

30 August 2010

Penalized for playing for "thrill and points"?

A player sent this note to me today:

"Hi Steven, I don't have a blog account so I use this form to react on your blog on very fast answers adjustment I think you are absolutely right to make some algorithm to weed out cheating. But as this is a quiz, you might disadvantage people who play for the thrill and the points as well as the pleasiure of learnig new things of PL/SQL. If I look at myself in the august 16 quiz, I read the question and knew that I didn't know the answer. I also knew it would take me a lot of time to look up the fully correct answer. The 5 answer looked as if they didn't exclude each other, and in my experience if you provide five answers probably most of them are correct. So I marked all of them and pressed submit as fast as I could. That gave me a decent 418 points, 329 less than the high score. I don't think that is cheating, it's just a strategy to play the game. By this strategy I could perhaps ond day have all correct choices, like on the 27th of August quiz after rescoring. Would behaviour like this be punished? That would seem unfair to me."

To which I reply:

You are correct, that is not cheating. It is a strategy to play that has little to do with learning PL/SQL. You can, though, choose this approach - but I am not going to organize the rules of the game around people who do not play primarily for the purposes of testing and improving their knowledge of PL/SQL. [Note: I am not claiming that you are playing with this strategy for all quizzes.]

As to the impact on your scores and rank, answering this way occasionally should not trigger a "very fast answer adjustment." This only occurs if your total time to answer over a two week period (minimum) is less than my total time to answer.

So, sure, feel free to - now and then - check all boxes or random boxes and press Submit, very quickly. But if you do this day after day, you will likely find yourself dropped like a stone in a river: to the bottom of the rankings.

Regards, SF

Answer question without testing?

A player asked this question today:

"Am I supposed to be able to answer these questions without actually running the code and testing it? :)"

Excellent question! When I take my own quizzes to establish "minimum reasonable time to answer" (which I then use to make adjustments for very fast answers), I rarely actually write code to verify the choices I make.

But I cannot imagine how, for many of these quizzes, you could not take the time to do this, if you wanted to really be certain that your choices were correct.

Here's another way of putting it: unless you have the same depth of familiarity with PL/SQL that I do, you would at best recognize the overall appropriateness of a given choice. You would be hard-pressed, however, to feel very certain that a choice is correct without writing some code to test out your hypothesis.

That is why so many players express deep skepticism when they see other players answer questions correctly in 20 seconds that they take over 100 seconds to sort through.

So, yes, by all means, write some code, test out the choices, and learn about the features of PL/SQL in a way that will stick in your brain (the reinforcement of typing out the code will help lots).

Cheers, Steven