|
From Our Readers
From Our Readers
Your corrections, your opinions, and your requests: Here's your forum for telling us what's right and wrong in each issue of Oracle Magazine, and for letting us know what you want to read.
No Landscaping Required
For the article at oracle.com/technology/oramag/oracle/04-may/o34tech_htmldb.html ("Serving HTML DB Reports," from the May/June 2004 issue of Oracle Magazine), I have to print the article in landscape to see all the text, even though I'm using your Printer View.
Christian Dethlefsen
chrd@novonordisk.com
We've made changes to the images in the online article, which allow the article text
to fit in a narrower page. You should now be able to print the article in portrait orientation. Thanks for pointing out this issue. Any reader who finds missing or unprintable content in issues of Oracle Magazine
online is encouraged to contact us at
opubedit_us@oracle.com.
Two Suggestions for Dual
Regarding the article "Self-Managing PL/SQL" by Steven Feuerstein in the May/June 2004 issue of Oracle Magazine, I wanted to raise two points, both regarding the DUAL table. Might I suggest that a user create his or her own DUAL table as an index-organized table (IOT), rather than a heap table? This will reduce logical I/Os significantly. If
you go with an IOT and define it with the following DDL
create table mydual(dummy varchar2(1) primary key constraint one_row check(dummy='X')) organization index;
you can avoid the overhead of a trigger and still protect the table from having more than one row. Note that the primary key protects against more than one row containing 'X' and the check constraint protects against any rows containing something other than 'X', which results in exactly one row containing 'X'.
Second, the idea to create the NEXT_PKY function utilizes EXECUTE IMMEDIATE. While I agree that there's no better way to do it unless you want to write an absurd amount of code, it should be noted that this would cause a PARSE call on each
execution that cannot be avoided. Again, because sequence generators can be heavily used pieces of code, the impact
of the extra parsing should be considered on highly concurrent systems.
Mark J. Bobak
mark@bobak.net
Thanks for raising these very interesting and valid points about my suggestion for replacing the DUAL table. I hope Oracle Magazine readers will put them to use wherever appropriate.
Steven Feuerstein
steven@stevenfeuerstein.com
Making Functions Function
In the article "Self-Managing PL/SQL" in the May/June 2004 issue of Oracle Magazine, I have a problem with Listing 2, line 4. I think there is a typographical error.
Ajani Olayide
layide_ajany@yahoo.com
You are absolutely correct. In Listing 2, there are two typographical errors, on both lines 4 and 6. The correct line 4 is
RETURN employee_level_rc
The correct line 6 is
RETVAL employee_level_rc
|
Send Mail to the Editor
Send your opinions about what you read in Oracle Magazine, and suggestions for possible technical articles, to opubedit_us@oracle.com.
Or click on the Write the Editors link on our Web site.
Letters may be edited for length and clarity and
may be published in any medium. We consider any communications we receive publishable.
|
The corrected version of Listing 2 is
now available online with the article at oracle.com/technology/oramag/oracle/04-may/o34tech_plsql.html.
Steven Feuerstein
steven@stevenfeuerstein.com
Approval, Request, and Correction
I read the article "Perform Without Waiting" in the July/August 2004 issue with great interest. An excellent work, especially the way the author introduced the concepts in much the same way a reader thinks and followed up with the rationale behind each action. Hopefully Oracle Magazine will carry more of such problem-centric articles in the future.
By the way, there is an error in a code listing in the article. In Listing 8, the column APPLICATION_WAIT_TIME value should be a number; instead it shows account_no = 333, which is clearly incorrect. I believe it should be 950 and the SQL_TEXT column value should be update accounts set balance = balance - 750 where account_no = 333. The meaning is not lost by this error, but it certainly looks funny in an otherwise flawless piece.
Gerard Macchione
gmacchione@excite.com
This was an editorial error. The corrected Listing 8 is online with the article at oracle.com/technology/oramag/oracle/04-jul/o44tech_perf.html.
|