Stored Procedure question

Question

I have a bunch of .sql scripts which I have created to do certain things. I have a modified excerpt of a PROC that already works but I have created a bunch of scripts that I want to run in the bottom of it. Can I run them one after another from the stored procedure something like this:
CREATE OR REPLACE PROCEDURE MYPROC(GET_CUR_PERIOD IN DATE, GET_PRIOR_PERIOD IN DATE)
IS
-- Define the DATE variables to be retrieved from initial script.
CUR_PERIOD DATE;
PRIOR_PERIOD DATE;
BEGIN
-- Assign the dates to this procedure that were passed in above.
CUR_PERIOD := GET_CUR_PERIOD; --07/27/2007
PRIOR_PERIOD := GET_PRIOR_PERIOD; --06/27/2007
-- Execute another stored procedure, passing in dates.
MYPROC2(CUR_PERIOD, PRIOR_PERIOD);
-- Some regular SQL statements go here
-- This is what I want to add - Will it work, and is the syntax correct?
@\\MyNetwork\MyFiles\MyFolder\script1.sql
@\\MyNetwork\MyFiles\MyFolder\script2.sql
@\\MyNetwork\MyFiles\MyFolder\script3.sql
End MyProc;
/

Answer 1

As long as myproc is defined in the package spec so it can be called externally, and myproc2 is defined in the package body, you should not have to make any changes to either of them in order to put them in a package. If you include myproc3 and myproc4 in the package as well, then either myproc or myproc2 could call them. Myproc's "thing" would include calling all of the procedures that it needs to do to do its job.
Just be aware that a procedure needs to be declared before it can be called. So, if myproc calls myproc2 and myproc2 is not defined in the specification, then myproc2 needs to be defined first in the package body. Although not strictly required as a format, my usual structure for package spec and body is along the lines of:
CREATE PACKAGE name AS
   signatures of public procedures and functions
   public variables and type
END;
CREATE PACKAGE BODY name AS
   package private variables and types
   package private procedures and functions (actual code)
   implementation of public procedures and functions
END;The number of public versus private procedures will depend on the nature of the tasks that the package is desinged to do. I have one package in our payroll system that produces either a text file to do our direct deposit for paying employees (EFT file), or a interface file to send to a GL system. There are 4 flavours of EFT file and 5 or 6 for the GL interface files.
Since both types of file use a number of common routines, I included them in a single package. There are two public procedures (run_eft(parameters), and run_gl(parameters)). There are about 50 private procedures or functions in the package each designed to do a single thing like
FUNCTION get_next_eft_number(company_id IN NUMBER) RETURN NUMBERwhich determines for a particular company what the next sequential file number id for that company's EFT file. The run_eft procedure looks kind of like:
PROCEDURE run_eft(parameters) IS
   variable declarations
BEGIN
  /* Check if pay is for this company and is completed */
  IF NOT validate_pay_run(p_run, p_co_id) THEN
     RAISE error;
  END IF;
  /* Get common info that all banks need */
  get_pay_date(p_run, l_paydate, l_chqdate);
  /* Get bank used by this company and bank specific info */
  get_bank_info(p_co_id, l_trans_cd, l_acct_no, l_bank_name);
  IF l_bank_name = 'BMO' THEN
     run_bmo_eft(parameters)
  ELSIF l_bank_name = 'RB' THEN
     run_rb_eft(parameters)
  ELSE
     RAISE BAD_BANK;
  END IF;
END;Both run_bmo_eft and run_rb_eft call other procedures to build corredtly formatted header, detail and trailer records as required by the bank. They also have a few procedures in common. Since the tables that tell me how much to pay a person are common across all of the companies, I use a single function to generate the cursor I walk to generate and format the output file.
"Doesn't this get unwieldly after a while, having to have all the code for all the procedures in one file? Or in practice does it actually help?" In practice, it actually helps a lot, as long as you do not get carried away. A package needs to contain related procedures, not every procedure you have ever created in the database.
To go back to my EFT/GL package as an example. I chose to create a single package initially because there were only two companies, both used the same bank for payroll, so the EFT files were identical. The GL systems differed, so I had two different procedures for those. However, there were a number of procedures such as the validate_pay_run proc I referred to that are common to both GL and EFT. We are now up to 5 or 6 companies using 4 different banks and all have different GL systems. In my opinion, this package is on the verge of becoming unwieldy. If we get another bank or two and one or two new GL systems to deal with, I will probably split the package. However, this is one of the benfits of using packages, I can do this easily with minimal disruption to the external users who run these jobs.
If I split, I would probably split it into 3 packages. One for the EFT specific processing, one for the GL interface processing, and one for the helper functions that are common to both. I would keep my current package spec as is as a wrapper so the users need to change nothing. My current and future spec looks like:
PACKAGE uhn_custom IS
   PROCEDURE run_eft(parmaeters);
   PROCEDURE run_gl(parameters);
END;However, the future body, instead of having the implementation details would be simply:
PACKAGE BODY uhn_custom IS
PROCEDURE run_eft(parmaeters) IS
BEGIN
   eft_package.run_eft(parameters);
END;
PROCEDURE run_gl(parameters) IS
BEGIN
   glint_package.run_gl(parameters);
END;
END;The only code changes I need make would be to preface all of the calls to the common helper functions in each package with the new helper_package name.
HTH
John