The issue was the libclntsh that Oracle was loading conflicted with SQLAnywhere , updating Oracle libs and recompiling DBD::Oracle fixes it. On Mar 7, 2017 2:10 PM, "Douglas Wilson" <douglasg.wil...@gmail.com> wrote:
> 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" <boh...@ntlworld.com> 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" <boh...@ntlworld.com >>> <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 >>> >>> >>
