Re: My cheesy workaround to ocilogon w/3rd param
| From: | Mike Hanney | Date: | Tue, 08 Aug 2000 17:25:26 +0000 |
| Subject: | Re: My cheesy workaround to ocilogon w/3rd param | ||
| References: | 1 | Groups: | php.db |
| Request: | Send a blank email to php-db+get-1863@lists.php.net to get a copy of this message | ||
Hi Paul,
You are not alone with your cheesy workaround, I'm doing exactly the same thing, almost line for line, just didn't want to admit it earlier.
I've tried all manner of putenv() too, and for the record, I think it's confusing how the optional third parameter in OCILogon should be an Oracle instance (entry in tnsnames.ora ?), but when it's omitted the Oracle SID environment var gets used instead. Seems inconsistent to me.
Mike.
At 09:54 08/08/00 -0700, Paul Fernandez wrote:
Hello again, I have come to the conclusion that f you use putenv() for a given user, ALL OTHER USERS will log into the new sid My cheesy workaround: If ($username == 'paul'){ $connection = OCIPLogon($username,$password,'dev'); // 3rd parameter will route to other sid } else {$connection = OCIPLogon($username,$password);} // goes to default apache http_env_var Notice that in the else statement, I do not use the 3rd parameter, thus forcing the user to rely on the environmental parameter, which is the production db. If I explicitly state it and merely pass in $db Somehow it works. I was unable to get the desired behavior by defining the 3rd parameter in every logon. Paul Fernandez wrote: I have inconsistent results using ocilogon to change between the development db (sid) and production db (sid), which both reside on the same oracle server. -- Paul Fernandez Webmaster Structural GenomiX, Inc. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: php-db-unsubscribe@lists.php.net For additional commands, e-mail: php-db-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net