It is in the DBI documentation.  Search for "0E0".

- Perrin


On Thu, Nov 7, 2013 at 12:41 PM, Xinhuan Zheng <xzh...@christianbook.com>wrote:

> So it returns string '0E0'? The document didn't say that.
>
> - xinhuan
>
> On 11/7/13 11:44 AM, "Adam Prime" <adam.pr...@utoronto.ca> wrote:
>
> >perl -e "if ('0E0') { print qq[hi\n] }"
> >hi
> >
> >OE0 as a string evaluates to true.  If you use it as a bareword /
> >numeric then it's false, which is what your eval example below is doing.
> >
> >Adam
> >
> >
> >On 13-11-07 11:29 AM, Xinhuan Zheng wrote:
> >> one correct - In both cases, the return value is evaluated to false.
> >>
> >> How do you distinguish?
> >>
> >> - xinhuan
> >>
> >> From: Xinhuan Zheng <xzh...@christianbook.com
> >> <mailto:xzh...@christianbook.com>>
> >> Date: Thursday, November 7, 2013 11:12 AM
> >> To: Perrin Harkins <phark...@gmail.com <mailto:phark...@gmail.com>>
> >> Cc: mod_perl list <modperl@perl.apache.org
> >><mailto:modperl@perl.apache.org>>
> >> Subject: Re: Apache::DBI connect
> >>
> >>> I don't actually understand why you did that.  What was wrong with the
> >>>normal ping?
> >>
> >> With Oracle DRCP, even though ping succeeds, the connection to the
> >> server process is actually terminated. Or ora_ping() may return 0E0
> >> "zero but true" and undef. I don't know. ora_ping() is foreign to me. I
> >> made the change based on what Apache::DBI the document said.
> >>
> >>> In any case, there's no need to change the Apache::DBI code, even with
> >>>your "select 1 from dual" test.   It returns a true value (0E0) if it
> >>>succeeds and a false value (undef) if it fails.
> >>
> >> In both cases, the return value is evaluated to true:
> >>
> >> 200: if ($Connected{$Idx} and (!$needping or
> >>eval{$Connected{$Idx}->ping}))
> >>
> >> eval{0E0} and eval{undef} both return true. I did test that. How do you
> >> distinguish?
> >>
> >>> Did your script succeed in reconnecting after it lost the connection?
> >>
> >> Yes.
> >>
> >>> Yes, I haven't forgotten about that, but I haven't had time to work on
> >>>it yet.  You can try fixing it yourself by looking at the code in
> >>>Apache::DBI that checks if the server is starting under apache 1.x.
> >>>Otherwise, I will eventually get to it.
> >>
> >> I don't understand that piece of code. I can't do the change. Hope you
> >> can help.
> >>
> >> - xinhuan
> >>
> >> From: Perrin Harkins <phark...@gmail.com <mailto:phark...@gmail.com>>
> >> Date: Thursday, November 7, 2013 11:00 AM
> >> To: Xinhuan Zheng <xzh...@christianbook.com
> >> <mailto:xzh...@christianbook.com>>
> >> Cc: mod_perl list <modperl@perl.apache.org
> >><mailto:modperl@perl.apache.org>>
> >> Subject: Re: Apache::DBI connect
> >>
> >> On Thu, Nov 7, 2013 at 9:46 AM, Xinhuan Zheng <xzh...@christianbook.com
> >> <mailto:xzh...@christianbook.com>> wrote:
> >>>The $ok is undef. In the case if the test does succeed (like the first
> >>>select), $ok returns 0E0.
> >>
> >> That all sounds good.  0E0 is a true value in Perl.  It means "zero but
> >> true."  And undef is a false value.  You don't need to test for undef.
> >>
> >>> Since I changed DBD::Oracle subroutine ping to use 'select 1 from
> >>>dual',
> >>
> >> I don't actually understand why you did that.  What was wrong with the
> >> normal ping?
> >>
> >> In any case, there's no need to change the Apache::DBI code, even with
> >> your "select 1 from dual" test.  It returns a true value (0E0) if it
> >> succeeds and a false value (undef) if it fails.
> >>
> >> Did your script succeed in reconnecting after it lost the connection?
> >>
> >>> I have another request. The Apache::DBI cached a dead database handle
> >>>for apache version 1.3.42 if  startup.pl <http://startup.pl> create a
> >>>database handle. The apache
> >> child processes inherits this dead handle. It doesn't cause application
> >> error but it does take memory space. If there is many apache processes,
> >> that's not good. Can you please identify and change the code for this
> >> problem?
> >>
> >> Yes, I haven't forgotten about that, but I haven't had time to work on
> >> it yet.  You can try fixing it yourself by looking at the code in
> >> Apache::DBI that checks if the server is starting under apache 1.x.
> >>   Otherwise, I will eventually get to it.
> >>
> >> - Perrin
> >>
> >
>
>

Reply via email to