RE: seperate external procedure listeners for different SIDs

2004-01-09 Thread Goulet, Dick
That's a wrinkle I had not thought about. Here, being a PeopleSoft shop, they like to run SQR's and sure enough they want to run the same sqr's from web pages, forms applications, etc. Well I took the stand that the external procedure could only be passed data. No you can't pass an sqr fi

RE: seperate external procedure listeners for different SIDs

2004-01-09 Thread John Flack
I'm not sure if I'd mentioned this before: We do use an external procedure to run external OS commands, but the procedure that is mapped to the C program is a private procedure in a package. The public interface to this procedure uses the PRODUCT_PROFILE (aka PRODUCT_USER_PROFILE) table to contr

Re: seperate external procedure listeners for different SIDs

2004-01-09 Thread Mladen Gogala
This is the only reasonable policy, because all OS commands would necessarily execute on the server side. Developers, generally speaking, do not have access to the database server, so I don't see much use for that. If the idea is to spawn a command on the developer's workstation by using "rsh" or "

RE: seperate external procedure listeners for different SIDs

2004-01-09 Thread Goulet, Dick
HUMM, I've taken a pretty tight stand against open ended external procedures and Java Stored Procedures. Thankfully the developers here agree. Basically I've told them that can't have an external or java procedure that executes a command send into it. That being the case rsh or sh command pr

RE: seperate external procedure listeners for different SIDs

2004-01-09 Thread John Dunn
Dick/John Thanks for all your input. I conclude from this discussion that it is not possible to have different, seperate external procedure listeners for different SIDs in the same instance at least not in 8.1.7. Incidentially, I have been having an issue with running an rsh command via an extern

RE: seperate external procedure listeners for different SIDs

2004-01-08 Thread Goulet, Dick
John, I agree if you have multiple databases under the same home all is well, one extproc sid will do. But if you have several different Oracle homes, with different versions of Oracle then each needs it's own extproc sid. Tried using the latest listener and/or extproc combinations, d

RE: seperate external procedure listeners for different SIDs

2004-01-08 Thread John Flack
Thanks - I wasn't sure if each session got its own instance of extproc. The SID associated with an EXTPROC is not the same as a SID associated with a database. I have several databases running under the same Oracle Home, and they are sharing the same external procedure listener - which referen

RE: seperate external procedure listeners for different SIDs

2004-01-08 Thread John Flack
That's pretty much it, at least through Oracle 8.1.7 (what I'm using). This is mostly because Oracle only uses one service name to make the connection, EXTPROC_CONNECTION_DATA, and TNSNAMES can only associate that service name with one IPC key. Therefore you can only talk to the one listener t

RE: seperate external procedure listeners for different SIDs

2004-01-08 Thread Goulet, Dick
John, On the contrary. You do need to associate an EXTPROC with a particular SID otherwise running different versions of Oracle on the same box blows the EXTPROC to hell. You'll notice that in listener.ora there needs to be a line "SID_NAME=" and in TNSNAMES.ora there is a "Connect_da

RE: seperate external procedure listeners for different SIDs

2004-01-08 Thread John Dunn
Hmm...so if for some reason I needed two external procedure listeners to run, (because, for example I wanted them to run as 2 different application users rather than oracle or use 2 different sets of .so files), I could not do it? -Original Message- Sent: 08 January 2004 14:20 To: Multip

RE: seperate external procedure listeners for different SIDs

2004-01-08 Thread John Flack
You're right - there isn't any tie between external procedures and a particular SID in the listener. Here's what I am guessing (educated guess based on the docs) happens: 1. Nothing supports external procedures until one is called. 2. When a session in a particular database instance calls an ex