RE: 4031 - errors

  • From: "Jamadagni, Rajendra" <Rajendra.Jamadagni@xxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 3 Jun 2004 08:23:25 -0400

Not a problem ... the switch should be controlled from outside the code,
and that means it can be changed dynamically at runtime in production if
needed. I implemented similar technique in 99 (I was a duheveloper
then), the debug code is still in production code, but turned off. 
 
all it takes a simple update and on the next invocation debug messages
are turned on. Here is the sample ... 
 
oraclei@ariel-NCS2> sys
SQL*Plus: Release 9.2.0.2.0 - Production on Thu Jun 3 08:22:27 2004
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Oracle Data
Mining options
JServer Release 9.2.0.2.0 - Production
 
08:22:28 SQL> select * from v_debug_state;
NAME                                     TYPE       Debug?
---------------------------------------- ---------- ----------------
DBPK_PACING_DATA                         PACKAGE    Debugging is Off
DBPK_RS100                               PACKAGE    Debugging is Off
DBPK_SBS_FINAL_LOG                       PACKAGE    Debugging is Off
DBPK_SBS_LOG                             PACKAGE    Debugging is Off
DBPK_SIDE_BY_SIDE                        PACKAGE    Debugging is Off

5 rows selected.
08:22:36 SQL> 

Raj
------------------------------------------------------------------------
--------
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
select standard_disclaimer from company_requirements;
QOTD: Any clod can have facts, having an opinion is an art ! 
 

  _____  

From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Duret, Kathy
Sent: Wednesday, June 02, 2004 5:40 PM
To: 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: 4031 - errors


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.
 
Kathy

        -----Original Message-----
        From: Jared.Still@xxxxxxxxxxx [mailto:Jared.Still@xxxxxxxxxxx]
        Sent: Wednesday, June 02, 2004 4:32 PM
        To: oracle-l@xxxxxxxxxxxxx
        Subject: RE: 4031 - errors
        
        

        oracle-l-bounce@xxxxxxxxxxxxx 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.

Other related posts: