Re: SQL*Plus scripts vs DBMS_JOB

I agree with you Daniel, for scripts that actually change data or structures,
but it's the scripts that are Select statements and spooled into specific files that we find hard to switch.
A script that is like this for example : spool file.txt
select this...;
select that...;
select something else...;
spool off
will need, as far as I know, when transferred into a procedure the use of cursors and UTL_FILE.
Which is less simple than my script example. Last year we looked for ways to call other programs through PL for other purposes and found none. We thought there might have been something new or some trick to do that. We use 8.1.6 so if it had been there we could have used it. Thanks for the response.
Serge

Daniel A. Morgan <dmorgan_at_exesolutions.com> wrote in message news:3AE3912A.441FA092_at_exesolutions.com...
> You can try DBMS_PIPE but I really don't understand why. Just turn each of
 your
> scripts into a procedure in a package. You can still execute them from the
> command line but you would have the advantage of also being able to
 execute them
> using DBMS_JOB.
>
> Why make things difficult for yourself just because they are small?
>
> Daniel A. Morgan
>
>
>
> B wrote:
>
> > As an Oracle dba team we have an increasing number of SQL*Plus scripts
> > called by a NT scheduler to do jobs on different Unix db servers. It is
> > somewhat practical, we can connect on any schema and especially spool
> > results where we want in the format we want. Now we want to migrate that
 to
> > Oracle jobs and use DBMS_JOB. It should be a better approach and most of
 the
> > jobs wil be better handled. But for some others small jobs the script
 method
> > is hard to beat.
> > Would anyone know of a rather simple way to still call SQL*Plus scripts
 from
> > within a Job ?
> > Would any Oracle-supplied packages would offer these kind of calls ?
> > It could make our lives easier !
> >
> > Thanks in advance.
> > Serge
>
Received on Sun Apr 22 2001 - 23:11:26 CDT