SQLPLUS Question
in [Oracle]
|
From: gazzag on 19 Jan 2010 05:34 On 18 Jan, 19:58, Mladen Gogala <n...(a)email.here.invalid> wrote: > On Mon, 18 Jan 2010 10:03:18 -0800, joel garry wrote: > > Are you spelling _his_ name correctly? :-) > > He is. > > --http://mgogala.byethost5.com I'm a frayed knot: http://groups.google.co.uk/group/comp.databases.oracle.server/search?hl=en&group=comp.databases.oracle.server&q=niall+litchfield&qt_g=Search+this+group HTH -g
From: Vladimir M. Zakharychev on 21 Jan 2010 10:37 On Jan 17, 7:34 pm, Jeremy <jeremy0...(a)gmail.com> wrote: > In article <hithhv$d1...(a)solani.org>, gogala.mla...(a)gmail.com says...> > > > > > On Sat, 16 Jan 2010 20:24:36 +0000, Jeremy wrote: > > > > In article <hit6ej$ph...(a)solani.org>, gogala.mla...(a)gmail.com says...> > > >> On Sat, 16 Jan 2010 18:37:24 +0000, Jeremy wrote: > > > >> > Can you create sqlplus scripts with "conditions" such that if for > > >> > example a SQL statement returns a particular value or error condition > > >> > then path A or path B is followed? > > > >> Yes. It's called PL/SQL and is available as of the version 6. > > > > Is that intended to be serious answer? > > > Yes. That is precisely what PL/SQL is intended for: you run SQL and > > follow some logic path depending on the outcome. > > Perhaps I assumed I had conveyed more of my requirements to the post > than I did. > > It's about conditional execution of .sql files - am looking at ways to > automate install/upgrades which cannot be done using PL/SQL. > > -- > jeremy SQL*Plus can do a lot more than most people expect. Check out how folks at Oracle are doing it: take any recent CPU patch and inspect catcpu.sql and you'll immediately see a way to launch .sql scripts conditionally; or take a look at @?/rdbms/admin/catbundle.sql for more complex example of conditional script *generation* and execution. The technique itself is not new: you combine PL/SQL for evaluating conditions and choosing scripts to run, bind variables to convey arguments and hold results, and SQL*Plus user variables to actually launch chosen scripts, possibly with chosen arguments. These patch application scripts are an excellent example of the technique you can build on. Regards, Vladimir M. Zakharychev N-Networks, makers of Dynamic PSP(tm) http://www.dynamicpsp.com
From: Jeremy on 21 Jan 2010 16:25 In article <0b6c2d7b-eba1-4923-8127- dd5b7dde582d(a)p24g2000yqm.googlegroups.com>, vladimir.zakharychev(a)gmail.com says...> > > > > It's about conditional execution of .sql files - am looking at ways to > > automate install/upgrades which cannot be done using PL/SQL. > > > > SQL*Plus can do a lot more than most people expect. Check out how > folks at Oracle are doing it: take any recent CPU patch and inspect > catcpu.sql and you'll immediately see a way to launch .sql scripts > conditionally; or take a look at @?/rdbms/admin/catbundle.sql for more > complex example of conditional script *generation* and execution. The > technique itself is not new: you combine PL/SQL for evaluating > conditions and choosing scripts to run, bind variables to convey > arguments and hold results, and SQL*Plus user variables to actually > launch chosen scripts, possibly with chosen arguments. These patch > application scripts are an excellent example of the technique you can > build on. Many thanks, the best and most relevant response to this thread. Though to be fair, I'm glad we all know how to spell each other's names now. -- jeremy
From: hpuxrac on 21 Jan 2010 19:09 On Jan 16, 6:15 pm, Mladen Gogala <gogala.mla...(a)gmail.com> wrote: snip > > Everyone knows you know a bit about it (Oracle). You know near to > > nothing about ksh. > > OK. You write me a script doing something related to Oracle in ksh and I > will write the same script in Perl. Let's compare the execution times and > the memory footprint. Also, as a minimum security measure, let's pack the > passwords in hexadecimal form, so that they're not visible from the > scripts at first glance. This is what I have in mind: Like almost always when you get a bee in your bonnet you start going overboard. Lots of us can do almost anything in ksh ... would it be nice if we had the time and inclination to do more in perl? Going down the path of proclaiming one scripting environment is better than another is a pretty good way to waste a lot of time but boring ... very very boring.
From: Mladen Gogala on 22 Jan 2010 10:47
On Thu, 21 Jan 2010 21:25:19 +0000, Jeremy wrote: > Many thanks, the best and most relevant response to this thread. Though > to be fair, I'm glad we all know how to spell each other's names now. Jerome, this was a very shrewd remark! -- http://mgogala.byethost5.com |