Re: DBD::SQLAnywhere SEGV when Oracle handle exists

[Douglas Wilson]

That does work, but I can't consider it a practical solution for this.
Through print/warns, I've determined it craps out at
sacapi->api.sqlany_connect(...), in dbdimp.c, but that's about as far as I
can get.

I will probably go back to using DBD::Sybase for IQ connections.
On Mar 7, 2017 10:11 AM, "Martin J. Evans"  wrote:

> On 06-Mar-17 5:38 PM, Douglas Wilson wrote:
>
>> After some searching, I tried using the ora_connect_with_default_signals
>> with INT and CHLD, and tried setting BEQUEATH_DETACH=yes in a local
>> sqlnet.ora, but still same result.
>>
>
> Try reversing the order in which you connect - if you can.
>
>
> On Mar 4, 2017 5:17 AM, "Martin J. Evans" > > wrote:
>>
>> On 02-Mar-17 10:54 PM, Douglas Wilson wrote:
>>
>> DBD::SQLAnywhere seems to work ok for Sybase IQ, but if I first
>> create a
>> DBD:Oracle handle, the SQLAnywhere connect hangs for a while, and
>> eventually segfaults. FYI on redhat Linux.
>>
>>
>> I don't have the info to hand right now but I've heard similar
>> reports before. I think it had something to do with the method used
>> to connect to Oracle and if that method is chosen it captures
>> SIGCHLD and maybe another signal as well.
>>
>> Martin
>> --
>> Martin J. Evans
>> Wetherby, UK
>>
>>
>

Re: DBD::SQLAnywhere SEGV when Oracle handle exists

[Martin J. Evans]

On 06-Mar-17 5:38 PM, Douglas Wilson wrote:

After some searching, I tried using the ora_connect_with_default_signals
with INT and CHLD, and tried setting BEQUEATH_DETACH=yes in a local
sqlnet.ora, but still same result.


Try reversing the order in which you connect - if you can.



On Mar 4, 2017 5:17 AM, "Martin J. Evans" mailto:boh...@ntlworld.com>> wrote:

On 02-Mar-17 10:54 PM, Douglas Wilson wrote:

DBD::SQLAnywhere seems to work ok for Sybase IQ, but if I first
create a
DBD:Oracle handle, the SQLAnywhere connect hangs for a while, and
eventually segfaults. FYI on redhat Linux.


I don't have the info to hand right now but I've heard similar
reports before. I think it had something to do with the method used
to connect to Oracle and if that method is chosen it captures
SIGCHLD and maybe another signal as well.

Martin
--
Martin J. Evans
Wetherby, UK

Re: (Fwd) Oracle.pm

[Bruce Johnson]

On Mar 6, 2017, at 5:59 PM, Gowtham 
mailto:shiningstargau...@gmail.com>> wrote:

Hi Ron,

I did that.
I have two scenarios here. Both the scenarios have same 
($dbh,$dbname,$user,$auth,$attr) values.
Scenario 1: executed code with ORACLE_HOME set to correct value.

Scenario 2: executed code with incorrect/wrong ORACLE_HOME env variable.

- So my code returns undef in the second scenario. I'm trying to understand the 
execution part inside the subroutine _login to establish the dependency of 
ORACLE_HOME on DBI connection.

$ORACLE_HOME is critical to any API involving oracle; this is not a function of 
_login or exclusive to DBI. If it’s set incorrectly or undef, you will always 
get a failure like this.

Without more details on your particular application, it’s difficult to 
determine why your script is failing, but most common is that the perl module 
is executed via some sort of process spawning a new shell and the environment 
in that shell is not properly set.

What you need to ensure that the environment variable $ORACLE_HOME is set in 
the process that is failing; either explicitly in the perl script  via 
$ENV{‘ORACLE_HOME’}= 'path to oracle_home’; or by ensuring that the defaults 
for the process include that variable.

In Apache you can set it via a SetEnv statement:

SetEnv ORACLE_HOME /path/to/oracle/home

Be aware that more than just ORACLE_HOME is needed, you also need to set 
LD_LIBRARY_PATH at a minimum, and perhaps TNS_ADMIN , ORACLE_BASE and 
ORACLE_SID.

--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs