> sql*plus is the wrong tool -- it does not have the capability to extract
> binary data to client files
>
> why is the customer specifying a shell script?

He does, and the question "why" is not a legitimate question to a
customer. He wants it and it is my task to evaluate if it is possible. Of
course I might find it is not possible.. in which case the customer would
have to alter their requirement but until then my job is to try with a
script.

> what's the environment? client/server? what's the client? is sql*plus
> installed on every client?

As I said in my original post, the client is a Solaris workstation and it
is obviously equipped with an Oracle client software. The platform of the
server is not known and I dont think it is relevant here. We can assume
client and server to be Ora9i.

> does the script need to be integrated into a system that already uses
> scripts?

I dont know that, its not part of the requirement. So for the moment I
assume it is a standalone script.

> if you're in a web-based environment, you could also use a simple PL/SQL
web
> toolkit app for file upload/download -- it's fairly straight-forward,

I am not. It is a simple Oracle client/server setup. No web or anything
mentioned.

AH

"André Hartmann" <andrehartmann@hotmail.com> wrote in message
news:413ee849$1@olaf.komtel.net...
| > sql*plus is the wrong tool -- it does not have the capability to extract
| > binary data to client files
| >
| > why is the customer specifying a shell script?
|
| He does, and the question "why" is not a legitimate question to a
| customer. He wants it and it is my task to evaluate if it is possible. Of
| course I might find it is not possible.. in which case the customer would
| have to alter their requirement but until then my job is to try with a
| script.
|

<editorial>
'why' is the MOST legitimate question to a customer -- that's how you
understand the problem and get it solved properly, rather than perpetuating
assumptions or solving the wrong problem, or providing the wrong solution to
the right problem

if you don't know why he wants SQL*Plus, and you don't know how the script
will be used, you're not able to solve the real business problem, only throw
stuff over the wall for the customer to try. i'd highly recommend getting
more information from the customer on what he's trying to accomplish. if you
know his real needs, not just his assumed solution, you can propose
appropriate solutions and eliminate trying inappropriate ones
</editorial>

++ mcs

André Hartmann wrote:

>> sql*plus is the wrong tool -- it does not have the capability to extract
>> binary data to client files
>>
>> why is the customer specifying a shell script?
>
> He does, and the question "why" is not a legitimate question to a
> customer.

Rubbish. Of course it's a legitimate question if it elicits real information
about the fundamental business need. Unless of course you are stuck with a
client who thinks he knows everything, and simply wants you to implement
his already-decided-upon solution.

But if he is approaching you for advice and insight, then you have a
*responsibility* to ask 'why'. Then your consulting assignment has a chance
of being of use to the client.

> He wants it and it is my task to evaluate if it is possible. Of
> course I might find it is not possible.. in which case the customer would
> have to alter their requirement but until then my job is to try with a
> script.

You don't even appear to know what the client *requirement* is. You know
what the client *thinks* is a solution. But that is not the same thing at
all.

>> what's the environment? client/server? what's the client? is sql*plus
>> installed on every client?
>
> As I said in my original post, the client is a Solaris workstation and
> it
> is obviously equipped with an Oracle client software. The platform of the
> server is not known and I dont think it is relevant here. We can assume
> client and server to be Ora9i.
>
>> does the script need to be integrated into a system that already uses
>> scripts?
>
> I dont know that, its not part of the requirement. So for the moment I
> assume it is a standalone script.

Oh dear. A consultancy assignment that starts on a bunch of assumptions is
going nowhere very fast. Stop assuming. Stop not knowing. Find out. Start
asking 'why'.

HJR

>
>> if you're in a web-based environment, you could also use a simple PL/SQL
> web
>> toolkit app for file upload/download -- it's fairly straight-forward,
>
> I am not. It is a simple Oracle client/server setup. No web or anything
> mentioned.
>
> AH
>

In article <ldKdnV7_X8gQdqPcRVn-hA@comcast.com>, Mark C. Stock says...
>
> "André Hartmann" <andrehartmann@hotmail.com> wrote in message
> news:413ee849$1@olaf.komtel.net...
> | > sql*plus is the wrong tool -- it does not have the capability to extract
> | > binary data to client files
> | >
> | > why is the customer specifying a shell script?
> |
> | He does, and the question "why" is not a legitimate question to a
> | customer. He wants it and it is my task to evaluate if it is possible. Of
> | course I might find it is not possible.. in which case the customer would
> | have to alter their requirement but until then my job is to try with a
> | script.
> |
>
> <editorial>
> 'why' is the MOST legitimate question to a customer -- that's how you
> understand the problem and get it solved properly, rather than perpetuating
> assumptions or solving the wrong problem, or providing the wrong solutionto
> the right problem
>
> if you don't know why he wants SQL*Plus, and you don't know how the script
> will be used, you're not able to solve the real business problem, only throw
> stuff over the wall for the customer to try. i'd highly recommend getting
> more information from the customer on what he's trying to accomplish. if you
> know his real needs, not just his assumed solution, you can propose
> appropriate solutions and eliminate trying inappropriate ones
> </editorial>
>

Spot on.

However I can see that it may be difficult sometimes... if your customer
is not the person with the business problem but someone perhaps
technical who has already decided that these are the things we will
explore.....

I for one *always* stop people from telling me how they want the system
to do things - and ask them to describe what they are trying to achieve
and then I'll take responsibility for making it happen

--

jeremy
_______________________________________
jeremy at hireserve dot com

> Rubbish. Of course it's a legitimate question if it elicits real
information
> about the fundamental business need. Unless of course you are stuck with a
> client who thinks he knows everything, and simply wants you to implement
> his already-decided-upon solution.

Hey, I am just a developer here. I dont even know the name, the company or
an email of the customer. I just get my tasks assigned by the management.
And my current task is what I have described in my original post. I am not
responsible for the communication with the customer and I am not in the
position to influence it.

When I posted here, I was expecting something like "yes, it works.. namely
this way..." or "no it doesnt work for this and that reason". That would
have been helpful, not an esoteric discussion that seems off-topic in this
group and that does not contribute to the solution of the current problem.

I feel that it is perfectly legitimate to ask whether a native client tool
like SQL*PLus or something else shipped with the Oracle client can perform a
BLOB fetch from the database to a local file without doing some programming
in a compiled language or not. Very often there are even two or more ways to
accomplish a specific task and no-one raises the question "why". you just
pick whats appropriate in your case.

"André Hartmann" <andrehartmann@hotmail.com> wrote in message
news:413f2f32$1@olaf.komtel.net...
| > Rubbish. Of course it's a legitimate question if it elicits real
| information
| > about the fundamental business need. Unless of course you are stuck with
a
| > client who thinks he knows everything, and simply wants you to implement
| > his already-decided-upon solution.
|
| Hey, I am just a developer here. I dont even know the name, the company
or
| an email of the customer. I just get my tasks assigned by the management.
| And my current task is what I have described in my original post. I am not
| responsible for the communication with the customer and I am not in the
| position to influence it.
|
| When I posted here, I was expecting something like "yes, it works..
namely
| this way..." or "no it doesnt work for this and that reason". That would
| have been helpful, not an esoteric discussion that seems off-topic in this
| group and that does not contribute to the solution of the current problem.
|
| I feel that it is perfectly legitimate to ask whether a native client
tool
| like SQL*PLus or something else shipped with the Oracle client can perform
a
| BLOB fetch from the database to a local file without doing some
programming
| in a compiled language or not. Very often there are even two or more ways
to
| accomplish a specific task and no-one raises the question "why". you just
| pick whats appropriate in your case.
|
|

it seems you got your answer early on - 'no, it doesn't'

however, most regular contributors to this group also try to find good
alternatives, and the only way you can identify good alternatives is to ask
'why' -- which is not esoteric, but mainline consulting -- and mainline for
this group.

you don't know what your choices are unless you ask why something is
needed -- not to challenge the customer, but to learn more about the
requirements.

don't be 'just a developer'. be a problem solver.

++ mcs

On Tue, 07 Sep 2004 21:36:21 -0700, Daniel Morgan <damorgan@x.washington.edu>
wrote:

>and if what is stuffed into that BLOB file is greater than a terabye in
>size what would you then propose to do with it?

But the OP is on 9i, not 10g. Then again, 4GB is still a fair bit to be
dumping through SQL*Plus :-)

Terabytes in a _single field_ is a bit scary...

--
Andy Hassall / <andy@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

"André Hartmann" <andrehartmann@hotmail.com> wrote in message news:<413f2f32$1@olaf.komtel.net>...
> > Rubbish. Of course it's a legitimate question if it elicits real
> information
> > about the fundamental business need. Unless of course you are stuck with a
> > client who thinks he knows everything, and simply wants you to implement
> > his already-decided-upon solution.
>
> Hey, I am just a developer here. I dont even know the name, the company or
> an email of the customer. I just get my tasks assigned by the management.

Who presumably (we hope) *do* know the name, the company and the email
of the customer. Unless you are working inside of a sealed box, use
the channels of communication that are available. No valid
devlelopment ever took place inside a sealed box with no understanding
of a customer's actual requirements.

> And my current task is what I have described in my original post. I am not
> responsible for the communication with the customer and I am not in the
> position to influence it.
>
> When I posted here, I was expecting something like "yes, it works.. namely
> this way..." or "no it doesnt work for this and that reason".

Come off it. You got told very early on in the piece that SQL Plus
does not handle blobs, but that PL/SQL does. There's your answer.

>That would
> have been helpful,

That *was* helpful, because that was the answer you were given.

> not an esoteric discussion that seems off-topic in this
> group and that does not contribute to the solution of the current problem.

Au contraire. It's not an esoteric discussion. It drives right to the
heart of providing a solution to this problem. Find out what the
customer's actual requirements are, instead of just accepting a bunch
of constraints that are imposed for no apparent rational reason, and
you will better be able to meet them, and solve the *client's* actual
problem.

> I feel that it is perfectly legitimate to ask whether a native client tool
> like SQL*PLus or something else shipped with the Oracle client can perform a
> BLOB fetch from the database to a local file without doing some programming
> in a compiled language or not.

Of course it's legitimate. And you got told, "No, SQL*Plus has no
functionality for that, but PL/SQL does". *You* keep coming back here
as though dissatisfied with that answer, so if some of us regulars
care to comment about the underlying issues here, that's our
privilege. And, who knows: maybe you could learn from it. But not if
you dismiss it as an irritating esoteric waste of your valuable time,
I suspect.

> Very often there are even two or more ways to
> accomplish a specific task and no-one raises the question "why". you just
> pick whats appropriate in your case.

The "why" is usually fundamental in working out what is actually
"appropriate". One of the good things about this group is that most
people here seem to instinctively know this, and won't just trot out a
simplistic answer unless they *know* it to be valid (there are always
exceptions, of course). And knowing requires asking.


HJR

Andy Hassall wrote:

> On Tue, 07 Sep 2004 21:36:21 -0700, Daniel Morgan <damorgan@x.washington.edu>
> wrote:
>
>
>>and if what is stuffed into that BLOB file is greater than a terabye in
>>size what would you then propose to do with it?
>
>
> But the OP is on 9i, not 10g. Then again, 4GB is still a fair bit to be
> dumping through SQL*Plus :-)
>
> Terabytes in a _single field_ is a bit scary...
>

In 10g you can put more into a single column in a single record than
will fit on the largest hard disk made.

So given that Oracle created this capability with some purpose in mind
.... anyone want to hazard a guess that doesn't involve storing video
and audio tape collected by government agencies?

--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace 'x' with 'u' to respond)

"André Hartmann" <andrehartmann@hotmail.com> wrote in message news:<413eb8fa$1@olaf.komtel.net>...
> > Can you tell us a little more on how you want to use the data? If a
> > future version of SQL*Plus were going to support BLOBs, what
> > commands/interface would be useful to you? Do you want the end result
> > to be a binary file? Since SQL*Plus output is traditionally character
> > based would a column of, say, uuencoded or base64 data be better than
> > hex encoding?
>
> In the cutomer's database we have binary content stored in LOBs, the
> binary content being for example .gif files, CCD (Catia Cadam Draft) files
> (that is CAD models), MS Office documents or fractions of those, movie files
> and so on.
>
> The customer requests a shell script (nothing compiled like C/C++) that is
> able to issue a SQL statement that would select a particulat LOB, for
> example "SELECT CCDContents FROM CADLibrary WHERE Id=4711" (where
> CCDContents is a BLOB column and Id is the primary key) and store the result
> (the stream of bytes that makes the LOB) in a local file on the client
> computer.
>
> With a little convincing we might get away with a Java/JDBC application
> if it is not possible otherwise. But of course I have to evaluate first
> whether it is possible otherwise, that's why I am doing.
>
> We do not expect to be the LOB size around a tera byte. The argest
> files/LOBs we have seen in our environment so far are 500MB and its not
> likely to exceed 1GB per LOB in the future. TB is just not a use case (for
> us) so I dont think about that.
>
> AH


Thanks for the feedback.

-- CJ