Excel question (was: Re: SQLPLUS Question)
Date: Sat, 16 Jan 2010 17:40:54 -0800 (PST)
Message-ID: <d33754b5-817e-45d6-94fb-4716970cabbf_at_a15g2000yqm.googlegroups.com>
On Jan 16, 12:37 pm, Jeremy <jeremy0..._at_gmail.com> wrote:
> In article <hit7pa$ph..._at_solani.org>, gogala.mla..._at_gmail.com says...>
>
>
>
> > On Sat, 16 Jan 2010 20:28:55 +0100, Gerard H. Pille wrote:
>
> > > I start sqlplus from a ksh script as a job, send queries to it and read
> > > the answers. ksh, which is also a full programming language, takes the
> > > decisions about how to continue.
>
> > That is, of course, a dangerous baloney wasting system resources. Neither
> > Korn shell nor Bash are the full fledged programming languages and adding
> > sqlplus in the mix guarantees security breaches. When I encounter a site
> > like that, the first thing I do is the following:
>
> > egrep -i "sqlplus|connect" *.sh
>
> > The result usually contains username and password combinations for the
> > most important schemas, the ones with the real company data. Sometimes,
> > the developers have a cunning plan and do something like this:
>
> > export CONNECTSTRING="scott/tiger_at_local"
>
> > and further down the script one can find
>
> > sqlplus $CONNECTSTRING << EOF
>
> > Well, guess what? I can get the content of that because I can open and
> > inspect the script. Even simpler, "ps -el|grep sqlplus>/tmp/owt.lis" will
> > reveal all the passwords. Just let me access the database server for 10
> > minutes and I'll collect your most important passwords. In addition to
> > that, activating programs is a rather expensive operations. Shell does
> > that at every turn: sqlplus, sed, ls, grep and awk are separate programs
> > which have to be found by shell, access rights checked, all the dynamic
> > libraries checked and loaded, which takes time and resources.
>
> > The real solution for scripting is using a real scripting language, like
> > Perl, PHP or Python. Concoctions with shell and sqlplus are cumbersome,
> > hard to read and insecure.
>
> All of the above may well be true, however if you are just trying to
> automate a simple task which involves running a specific set (depending
> on some conditions in the database for example) of .sql files on demand
> by the DBA then this may well be the simplest way of achieving the
> objective.
>
> --
> jeremy
Mladen is perfectly correct. I must say, however, that I do lots of ksh/awk types of programming, simply because I'm conversant enough in it to blast it out fast and stupid. Perfectly appropriate for brainless requests. I've been intending on becoming as conversant in perl for a decade or more now, but it is indeed cheaper to do it over than do it right.
It's nothing compared to people who want to use Excel as the data entry solution, and then expect me to come up with a way to get that into Oracle. I do not seem to be able to convince people who ought to know better that there are reasons for constraints on data in the database and the application, and it is difficult to tell Excel about them. I can understand people wanting to use Excel, it is a tool the users "know," and it is easy to get data out of the db and into it. I've been able until now to use unix tools, but that's not something I can really give to a user, as they can screw with the data in unlimited ways to achieve errors I must fix.
Somehow, this has become an official "goal" for me. I feel doomed as doomed can be. I've seen some examples from Charles Hooper's blog, but they are still beyond my mental grasp. Any suggestions appreciated.
jg
-- _at_home.com is bogus. http://www.signonsandiego.com/news/2010/jan/16/alibaba-says-yahoo-reckless-on-google-stance/Received on Sat Jan 16 2010 - 19:40:54 CST