Re: Oracle #1? Then why are these still missing...

Mark Styles wrote:

>gary_at_onegoodidea.com (Gary O'Keefe) instructed their monkeys to type:

Monkey butlers are the best, aren't they? Everyone should have a monkey butler.

>>3. Printing without having to "set serveroutput on" and
>>"dbms_output.enable(...)". I want to print. I wouldn't have written a
>>script with dbms_output.put_line if I didn't want to see it.
>
>What about if you're using it for debug? Personally I use DBMS_PIPE
>for debugging, but some people use DBMS_OUTPUT, and like to be able to
>turn it on only when they need to debug.

Then the default behaviour should be to display the output unless told otherwise.

>>4. Raise the output buffer size > 1Mb. This is the 90's for goodness
>>sake. Are we still farting around with teeny DBs? I don't think so.
>
>It already is more than 1Mb

I'm still using 7.2.3.2. It appears progress has been made without me. How inconsiderate.

>>The file and print handling in Oracle is so bad that I have given up
>>on PL/SQL in favour of perl. Using the DBD interface is about as fast
>>as PL/SQL and it is *so much* easier to manipulate and format the
>>results of queries it is untrue.
>
>PL/SQL isn't designed for file and print handling. Oracle have
>supplied some packages to give us some outside of the DB
>functionality, but fundamentally PL/SQL is designed to manipulate data
>in a relational database.

Yeah, but no man is an island. The database exists in an environment where data has to be collated from a vast number of different sources, and it has to be distributed to a wide variety of destinations. To ignore the outside world as blatantly as PL/SQL does is folly. We are talking about basic, functional IO. Nothing special.

>If you want true database/OS interaction, use any of the Pro*
>compilers, or use perl.

Perl's OK (*way* better than PL/SQL), but the overheads that have to be set up before the script will function get a bit tiresome quite quickly. Pro*C I might consider for purely internal batch processing, and maybe for a particular, well defined task with a specification unlikely to change in the short- to medium-term and which must be run a large number of times. But for ad hoc work involving date pre-processing and loading it would be lousy.

Gary
--
Gary O'Keefe
gary_at_onegoodidea.com

You know the score - my current employer has nothing to do with what I post Received on Thu Jul 29 1999 - 05:37:15 CDT