1 2 Previous Next 17 Replies Latest reply on Mar 13, 2007 3:31 PM by Billy~Verreynne Go to original post
      • 15. Re: pl/sql event logging
        ABB
        Adrian Billington provides a "REPLACEF" function for
        just such a purpose at the excellent (IMO)
        http://www.oracle-developer.net, see...

        http://www.oracle-developer.net/content/utilities/repl
        acef.sql
        Thanks for the plug Padders ;o)

        BTW, you've added a comma to the site's URL, it should be http://www.oracle-developer.net.

        Regards
        • 16. Re: pl/sql event logging
          mlindsay
          The original RaiseError() however did simply raise an application error.. Comes from >refactoring code. I'm always refactoring code when it needs to be touched. :-)
          I figured that was the reason, I am also guilty of such behavior.
          Hmm.. how would you handle something like this? An API call that outgrows its original >base functionality due to it being refactored and improved - where a name change to the >API call would be in order?
          Make sure the API procedure names have no meaning to begin with i.e. proc_1, proc_2, proc_3 ;-)

          On a more serious not the impact of this sort of change can be reduced by generating as much code as possible. For the code that isn't generated i would probably ask the guys in our office who know Ruby to write me a script to implement the change across the multiple files.

          Difficulties come when an interface params are changed.

          You could of course go for the compromise and make sure the procedure is well documented and the documentation for it is updated along with any changes therefore reducing the reliance on the actual name of the procedure.

          In the end we should all resort to having one package called "X" we should then create a procedure called "Y" and all other procedures should be overloaded variants of "Y". Problem solved!!
          • 17. Re: pl/sql event logging
            Billy~Verreynne
            I was figuring like implemening a ProcessError(), update the API specs on our developer wiki, and changing the RaiseError() to include the following code:

            if SYSDATE > TO_DATE( '2008', 'YYYY') then
            raise_application_error( -20001, 'API call deprecated. Idiot..' );
            end if;
            I like though the idea of calling it proc_1, proc_2 etc. But this must be applied consistently across tables and columns.. in fact all database objects.

            There are numerous advantages to this approach. Especially job security wise...
            1 2 Previous Next