Re: Calling shell command from stored procedure

Comments embedded

Regards,

Sybrand Bakker, Oracle DBA

<daning_at_my-deja.com> wrote in message news:8ptt6a$gr0$1_at_nnrp1.deja.com...
> Hi all,
>
> 1. What do you think the best way to call OS shell command from stored
> procedure?
>
> 2. Since the only way I know is to create an external procedure to call
> a DLL. You know that setting up calling external procedure is
> complicated in Oracle. I want our product could be automatically
> installed. I don't want the DBA to do some manual work for our
> products.

Do I understand you correctly you are endeavouring *forcing* installation in a *separate* instance. Because otherwise, why would you need to *screw* with the tnsnames.ora and listener.ora.
I'm sure DBAs will just *love* you for this. A DBA usually is someone who wants to stay in control, and usually has to deal with problematic third party sw more often than he wants to. It looks like your sw is going to be, from the DBA viewpoint, *extreemly inflexible*

Why this distrust in DBAs?
We are keeping your sw in the air, don't we? Or do you think your product is capable of doing without a DBA?

So I am going to write a small program to set up tnsname.ora
> and listener.ora. But I get a problem that when in a multiple instance
> environment; I just could not find the files that the listener uses are
> located in with Oracle home directory. I searched the registry, but I
> could not find how the Oracle did the trick.
>
> Thank you in advance.
>

I would simply forget about this.

In a multiple instance situation (I'm still assuming you're going to force a specific instance to be used), you can
't *overwrite* (which is what you are saying here) an already existing listener.ora and tnsnames.ora.

Usually multiple instances or not, there's only one tnsnames.ora and listener.ora on a server.

If the TNS_ADMIN hasn't been set in the registry, they will be located in a default directory which is version specific. You can find those locations in sqlnet administrators manuals without problem.

So your 'small program' would need to *edit* an *existing* listener.ora and tnsnames.ora.
If I would discover there is some product on my system, which is taking decisions *for* me (in this case *edit* my tnsnames.ora), instead of having me making my own decisions, I would immediately *dump it*.

Again DBAs will *love* your this. Received on Fri Sep 15 2000 - 15:10:02 CDT