Re: How to print column heading only in SQL plus

On 2013-09-14, Mladen Gogala <gogala.mladen_at_gmail.com> wrote:
> On Sat, 14 Sep 2013 21:37:19 +0000, Mladen Gogala wrote:
>
>> On Sat, 14 Sep 2013 19:05:45 +0100, Eric wrote:
>>
>>> If I write Perl, no-one else on the site can understand it - sometimes
>>> I'm not sure I can. And it doesn't officially exist anyway, even though
>>> our database servers tend to have two installations, the one in oracle
>>> and the one in Data Protector (formerly omniback).
>>
>> They can only take Perl from my cold, dead hand!
>
> I have thought about leaving this at that "in your face" one-liner, but
> then decided against that. Perl is one of the best known scripting
> languages in the world. If your administration staff, be it DBA or SA,
> don't know Perl and you're not a Windows shop, then your company is
> employing the wrong people.
> As for the virtues of shell, yes, it is a glue. If overused, it gives
> birth to an IT equivalent of what is known as "junk art" among the art
> connoisseurs. Personally, I have bad experience with that, too. I was
> employed by the company who wrote the whole process of creating a standby
> database as a shell script. They didn't want to use Data*Guard and
> dg_broker because the lead DBA didn't know it and didn't understand it.
> Needless to say, I didn't stay with that company for a long time.
> My post doesn't say just "use Perl", what I'm advocating is using the
> right tool for the job. There is one thing that I'm sure of: sqlplus is
> not a report writing tool. It doesn't matter how much of sed, awk, cut
> and grep you glue to it, it will never become a good report writing tool.
> For that matter, neither will Perl. Perl has built-in "format" directive
> which can do certain things really well, like printing fixed column
> headers, page headers and doing page breaks, there is even more powerful
> CPAN module called Perl6::Form, but neither can deal with things like
> groups and totals, which are marks of any decent report writing tool like
> RLIB, Jasper or Pentaho. In the dawn of the IT industry when IT apes were
> breaking each others skulls with the bones of dead animals (my apologies
> to Stanley Kubrick), there were programming languages like COBOL and RPG
> which have both had more powerful report generating capabilities than
> Perl has today. When the black monolith landed, there was a tool called
> RPT/RPF, which has worked with Oracle 5 and Oracle 6. That tool has also
> had much more report writing capabilities than Perl. Perl is a lousy
> excuse for a report writing tool and you need something better.
> However, Perl is a great scripting language which results in neat, clean
> and understandable scripts and can be used as a glue between Oracle and
> OS. In contrast with shell, Perl has very decent mechanisms for working
> with arrays, both integer-based and associative, it has excellent file
> handling mechanisms, signal handling, argument parsing and debugging
> capabilities, far beyond the level of any shell. Above all other,
> programming in Perl is fun. Programming shell scripts is working on the
> chain gang.

I would have left it at the one-liner but...

. Not the wrong people, just the effect of priorities in a small   organisation.

. Right tool for the job of course, but "right" always has a context.

. Gluing anything in to post-process SQL*Plus output was not in my mind   at all here.

. SQL*Plus does groups and totals!

. Perl's "format" is, surprise, surprise, pretty handy for formatting,   and rolling your own groups and totals is easy in Perl (if you know it   well enough).

. Someone else has already doubted "neat, clean and understandable" in   this thread. I agree with them (except about Ruby, which I haven't   tried).

. "Fun" is personal and subjective.

Eric

-- 
ms fnd in a lbry