On 14/01/11 15:01, H.Merijn Brand wrote: > On Fri, 14 Jan 2011 14:56:46 +0000, "Martin J. Evans" > <martin.ev...@easysoft.com> wrote: > >> On 14/01/11 14:30, H.Merijn Brand wrote: >>> Maybe this is a feature request, but if I have >>> >>> ORACLE_USERID=john/sekrit >>> DBI_USER=pablo >>> DBI_PASS=neruda >>> >>> I *do* expect that DBD::Oracle uses DBI_USER and DBI_PASS *instead of* >>> the ORACLE_USERID. Anyone can come up with a good reason why this os >>> not happening at the moment? >>> >>> How do other DBD's set precedence if environment variable are allowed >>> for login credentials? >>> >> >> Just a minor point (not saying it stops the discussion) but I don't >> think ORACLE_USERID is something DBD::Oracle defines (other than in >> test code in t/*). So is your point to do with running tests in t/* or >> in general? > > I ran into this in the test suite indeed. Your findings below just > confirm my expectation :) > > I posted it here because I saw no generic docs about this
It is in the README. The supplied tests will connect to the database using the value of the ORACLE_USERID environment variable to supply the username/password. Don't know why it cannot fall back on DBI_USER/DBI_PASS. >> $ export ORACLE_USERID=wrong/wrong >> $ export DBI_USER=real_user >> $ export DBI_PASS=valid_password >> $ export DBI_DSN='dbi:Oracle:host=betoracle.easysoft.local;sid=devel' >> $ perl -le 'use DBI; my $h = DBI->connect();' >> >> works for me. i.e., ORACLE_USERID contains invalid username/password >> and DBI_USER/DBI_PASS contain valid username/password and it connects >> fine. >> >> Perhaps I misunderstood you Merijn. >> >> Martin > > Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
