the trouble with the switch here it that the developers forget to switch it
off.
I totally agree with the many functions, procedure rule. I tried today to
get them to break it up, but getting the developer and the other choke dba
to change their code is harder than
carving another face on mount Rushmore.
BTW loved your comment Johnathan... yet another top has coffee stains all
over it. I have to remember to put down my drink before I read these
emails.
oracle-l-bounce@(protected) wrote on 06/02/2004 02:03:38 PM:
> OK - here are some things that contributed to my problems and woes:
>
> 3) The other choke, gasp, dba had alot of dbms_outputs in procedure,
> functions except that he moved into production instead of commenting them
> out.
Commenting them out is bad form for production code. A switch that can
be set at runtime to enable/disable the debug code is quite a bit better.
The default of course should be false.
Jared
> one procedure that called another function which called another
> function, had more than 20 of these things. And yes same person who is
> updating
> across the links.....
>
Many functions is better than 1 big one. You just need to implement
a trace mechanism to trace the call stack when the, *ahem*, debug
flag is set.
Jared
This transmission contains information solely for intended recipient and may
be privileged, confidential and/or otherwise protect from disclosure. If
you are not the intended recipient, please contact the sender and delete all
copies of this transmission. This message and/or the materials contained
herein are not an offer to sell, or a solicitation of an offer to buy, any
securities or other instruments. The information has been obtained or
derived from sources believed by us to be reliable, but we do not represent
that it is accurate or complete. Any opinions or estimates contained in
this information constitute our judgment as of this date and are subject to
change without notice. Any information you share with us will be used in
the operation of our business, and we do not request and do not want any
material, nonpublic information. Absent an express prior written agreement,
we are not agreeing to treat any information confidentially and will use any
and all information and reserve the right to publish or disclose any
information you share with us.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN " >
<HTML > <HEAD >
<META HTTP-EQUIV= "Content-Type " CONTENT= "text/html; charset=iso-8859-1 " >
<META content= "MSHTML 6.00.2800.1400 " name=GENERATOR > </HEAD >
<BODY >
<DIV > <FONT face=Arial color=#0000ff size=2 > <SPAN class=966393421-02062004 >the
trouble with the switch here it that the developers forget to switch it
off. </SPAN > </FONT > </DIV >
<DIV > <FONT face=Arial color=#0000ff size=2 > <SPAN
class=966393421-02062004 > </SPAN > </FONT > </DIV >
<DIV > <FONT face=Arial color=#0000ff size=2 > <SPAN class=966393421-02062004 >I
totally agree with the many functions, procedure rule. I tried today to
get them to break it up, but getting the developer and the other choke dba to
change their code is harder than </SPAN > </FONT > </DIV >
<DIV > <FONT face=Arial color=#0000ff size=2 > <SPAN
class=966393421-02062004 >carving another face on mount Rushmore.
</SPAN > </FONT > </DIV >
<DIV > <FONT face=Arial color=#0000ff size=2 > <SPAN
class=966393421-02062004 > </SPAN > </FONT > </DIV >
<DIV > <FONT face=Arial color=#0000ff size=2 > <SPAN class=966393421-02062004 >BTW
loved your comment Johnathan... yet another top has coffee stains all over
it. I have to remember to put down my drink before I read these
emails. </SPAN > </FONT > </DIV >
<DIV > <FONT face=Arial color=#0000ff size=2 > <SPAN
class=966393421-02062004 > </SPAN > </FONT > </DIV >
<DIV > <FONT face=Arial color=#0000ff size=2 > <SPAN
class=966393421-02062004 >Kathy </SPAN > </FONT > </DIV >
<BLOCKQUOTE >
<DIV class=OutlookMessageHeader dir=ltr align=left > <FONT face=Tahoma
size=2 >-- --Original Message-- -- <BR > <B >From: </B > Jared.Still@(protected)
[mailto:Jared.Still@(protected)] <BR > <B >Sent: </B > Wednesday, June 02, 2004 4:32
PM <BR > <B >To: </B > oracle-l@(protected) <BR > <B >Subject: </B > RE: 4031 -
errors <BR > <BR > </FONT > </DIV > <BR > <FONT size=2 > <TT >oracle-l-bounce@(protected)
wrote on 06/02/2004 02:03:38 PM: <BR > <BR >> OK - here are some things that
contributed to my problems and woes: <BR >> <BR >> 3) The other
choke, gasp, dba had alot of dbms_outputs in procedure, <BR >> functions
except that he moved into production instead of commenting them <BR >>
out. <BR > </TT > </FONT > <BR > <FONT size=2 > <TT >Commenting them out is bad form for
production code. A switch that can </TT > </FONT > <BR > <FONT size=2 > <TT >be
set at runtime to enable/disable the debug code is quite a bit
better. </TT > </FONT > <BR > <BR > <FONT size=2 > <TT >The default of course should be
false. </TT > </FONT > <BR > <BR > <FONT size=2 > <TT >Jared </TT > </FONT >
<BR > <BR > <BR > <FONT size=2 > <TT >> one procedure that
called another function which called another <BR >> function, had more than
20 of these things. And yes same person who is <BR >> updating <BR >>
across the links..... <BR >> <BR > </TT > </FONT > <BR > <FONT
size=2 > <TT >Many functions is better than 1 big one. You just need to
implement </TT > </FONT > <BR > <FONT size=2 > <TT >a trace mechanism to trace the call
stack when the, *ahem*, debug </TT > </FONT > <BR > <FONT size=2 > <TT >flag is
set. </TT > </FONT > <BR > <BR > <FONT size=2 > <TT >Jared </TT > </FONT >
<BR > </BLOCKQUOTE > </BODY > </HTML >
<BR >
<BR >
<BR >
<P > <FONT SIZE=2 FACE= "Arial " >This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information constitute our judgment as of this date and are subject to change without notice. Any information you share with us will be used in the operation of our business, and we do not request and do not want any material, nonpublic information. Absent an express prior written agreement, we are not agreeing to treat any information confidentially and will use any and all information and reserve the right to publish or disclose any information you share with us. </FONT > </P >
