> On Thu, Feb 19, 2009 at 2:08 PM, <sco...@pythian.com> wrote:
>
>> > oracle instant client 11.1
>>
>> I wonder if they have changed how 11.1 works?? wil have to look at that
>>
>> what was the ORacle version working with 1.16?
>
>
>
> 9.2.0
>
Ok that would explain it. This older client would use a now depricated
connection method.
What you seeing is normal behaviour
cheers
John Scoles
>
>
>>
>>
>> > But it seems to work now using the 'ora_envhp => 0' attribute. Is
>> there
>> > some
>> > penalty performance when using this option ?
>> >
>>
>> Not in terms of speed it does use a little more resources so it is not
>> something you want to use on a mass scale say on a large web server or
>> alike.
>>
>>
>> > On Thu, Feb 19, 2009 at 1:56 PM, <sco...@pythian.com> wrote:
>> >
>> >> What is the version of the Oracle client you are using?
>> >>
>> >> There is a rather large gap between 1.16 and 1.22 on the way they
>> >> connect
>> >> especially with the older Oracle clients which could explain his
>> >>
>> >> cheers
>> >> John Scoles
>> >>
>> >> > On Thu, Feb 19, 2009 at 12:33 PM, Martin Evans
>> >> > <martin.ev...@easysoft.com>wrote:
>> >> >
>> >> >> Karl Forner wrote:
>> >> >>
>> >> >>> I'm experiencing a very strange problem : in short, I could not
>> >> >>> reconnect
>> >> >>> to a DB using DBI once I successfully connected then failed (with
>> >> bad
>> >> >>> password for example), IN THAT ORDER.
>> >> >>>
>> >> >>> I made a script reproducing the bug:
>> >> >>> =================
>> >> >>> #!/usr/bin/env perl
>> >> >>> use strict;
>> >> >>> use warnings;
>> >> >>> use DBI;
>> >> >>>
>> >> >>> my $dsn = 'dbi:Oracle:sid=TITI;host=xxx.yyy.zzz.com;port=1521';
>> >> >>> my $user = 'toto';
>> >> >>> my $password = $user;
>> >> >>> my $options = { AutoCommit => 0 };
>> >> >>> my @goodinfo = ($dsn, $user, $password, $options);
>> >> >>> my @badinfo = ($dsn, $user, '', $options);
>> >> >>>
>> >> >>> test(@goodinfo);
>> >> >>> test(@badinfo);
>> >> >>> test(@goodinfo);
>> >> >>> test(@goodinfo);
>> >> >>>
>> >> >>> sub test {
>> >> >>> my $dbh;
>> >> >>> eval { $dbh = DBI->connect(@_) };
>> >> >>> warn "$...@\n" if $@;
>> >> >>> print $dbh ? "Ok" : "NOK";
>> >> >>> print "\n";
>> >> >>> }
>> >> >>>
>> >> >>> ========
>> >> >>>
>> >> >>> so I expect to get "OK NOK OK OK".
>> >> >>> But on one computer I get "OK NOK NOK NOK", and on another I get
>> the
>> >> >>> expected stuff (using the same database)
>> >> >>>
>> >> >>> But if I do
>> >> >>> test(@badinfo);
>> >> >>> test(@goodinfo);
>> >> >>> test(@goodinfo);
>> >> >>>
>> >> >>> I get "NOK OK OK" on both !!!!!!!
>> >> >>>
>> >> >>> Is this a bug ??
>> >> >>>
>> >> >>> Thanks
>> >> >>> Karl Forner
>> >> >>>
>> >> >>> P.S
>> >> >>>
>> >> >>> Here are the configs :
>> >> >>>
>> >> >>> working computer:
>> >> >>> arch: ia64
>> >> >>> OS: Suse ES 9
>> >> >>> perl -v : v5.8.6
>> >> >>> DBI: 1.607
>> >> >>> DBD::Oracle: 1.16
>> >> >>>
>> >> >>> buggy computer:
>> >> >>> arch: i686
>> >> >>> OS : ubuntu 8.04
>> >> >>> perl -v : v5.8.8
>> >> >>> DBI: 1.601
>> >> >>> DBD::Oracle: 1.22
>> >> >>>
>> >> >>>
>> >> >> I think if you add add "ora_envhp => 0" to your options it will
>> work.
>> >> >> See the DBD::Oracle pod for an explanation.
>> >> >>
>> >> >
>> >> > Indeed it works, thnak you.
>> >> > I think this is something quite dangerous and difficult to solve,
>> >> maybe
>> >> it
>> >> > should be a default or clearly explained in the synopsis.
>> >> > Typical use case it testing a list of login/password. Here the
>> >> connection
>> >> > begins to fail as soon as there is a success followed by a failure,
>> >> then
>> >> > all
>> >> > subsequent connections fail.
>> >> > Moreover it does not happen with previous version of DBD::Oracle.
>> >> >
>> >> > Thanks again for the answer.
>> >> >
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>
