RE: segfault in Oracle libraries when SIGINT received

2010-09-10 Thread John Scoles
Can you run the test suite of DBD::Oracle and see what you get? If it passes that then it is some sort of Catalyst config problem. Cheers John Scoles > Date: Fri, 10 Sep 2010 11:05:30 -0500 > Subject: segfault in Oracle libraries when SIGINT received > From: pc88m...@gmail.com > To: dbi

Re: SQL errors not making it back to Perl

2010-09-10 Thread Martin J. Evans
On 10/09/10 17:10, Roode, Eric wrote: > Oho! Here is a clue. I removed > > odbc_cursortype => 2 > > from the DBI->connect attributes. Now the error is trapped! > The output was: > > handle_error: $state is "42000". > handle_error: $msgis "[Microsoft][ODBC SQL Server Driver][S

Re: SQL errors not making it back to Perl

2010-09-10 Thread Martin J. Evans
On 10/09/10 17:01, Roode, Eric wrote: > On Friday, September 10, 2010 11:47 AM, Martin J. Evans wrote: > >> You don't look like you did anything but connect and disconnect. You >> are running it on the script you posted originally aren't you? >> >> Can you try again. Remove the use DBD::ODBC and c

RE: SQL errors not making it back to Perl

2010-09-10 Thread Roode, Eric
Oho! Here is a clue. I removed odbc_cursortype => 2 from the DBI->connect attributes. Now the error is trapped! The output was: handle_error: $state is "42000". handle_error: $msgis "[Microsoft][ODBC SQL Server Driver][SQL Server]An error was raised. Input was "Some input par

segfault in Oracle libraries when SIGINT received

2010-09-10 Thread E R
If I hit Control-c after starting up the standalone catalyst server without the -r option, I'll get a segfault. Here is the backtrace: #0 0xb6240a07 in nsgetcinfo () from .../rnapps/oracle/libclntsh.so.10.1 #1 0xb62658c8 in nioqih () from .../rnapps/oracle/libclntsh.so.10.1 #2 0xb626bb49 in ni

RE: SQL errors not making it back to Perl

2010-09-10 Thread Roode, Eric
On Friday, September 10, 2010 11:47 AM, Martin J. Evans wrote: > You don't look like you did anything but connect and disconnect. You > are running it on the script you posted originally aren't you? > > Can you try again. Remove the use DBD::ODBC and connect flags I > asked you to add and simply d

Re: SQL errors not making it back to Perl

2010-09-10 Thread Martin J. Evans
On 10/09/10 16:30, Roode, Eric wrote: > On Friday, September 10, 2010 3:58 AM, Martin J. Evans wrote: > >> On 09/09/10 21:20, Roode, Eric wrote: >>> On Thursday, September 09, 2010 4:14 AM, Martin J. Evans wrote: > [...] You could send me a level 15 trace and I might see something but it

RE: SQL errors not making it back to Perl

2010-09-10 Thread Roode, Eric
On Friday, September 10, 2010 3:58 AM, Martin J. Evans wrote: > On 09/09/10 21:20, Roode, Eric wrote: > > On Thursday, September 09, 2010 4:14 AM, Martin J. Evans wrote: [...] > >> > >> You could send me a level 15 trace and I might see something but it > >> looks like raiserror in your case is no

Re: SQL errors not making it back to Perl

2010-09-10 Thread Peter J. Holzer
On 2010-09-10 07:01:26 -0400, Martin Gainty wrote: > Your SQLNET.ORA file should contain the following lines to produce a > client side trace file: trace_level_client = 10 I don't think SQLNET.ORA will have much effect on MS SQL Server ;-). hp -- _ | Peter J. Holzer| Auf jedem C

RE: SQL errors not making it back to Perl

2010-09-10 Thread Martin Gainty
Martin is correct to enable tracing: Client Side Tracing: Your SQLNET.ORA file should contain the following lines to produce a client side trace file: trace_level_client = 10 trace_unique_client = on trace_file_client = sqlnet.trc trace_directory_client = Server Side Tracing: To enable ser

Re: SQL errors not making it back to Perl

2010-09-10 Thread Martin J. Evans
On 09/09/10 21:20, Roode, Eric wrote: > On Thursday, September 09, 2010 4:14 AM, Martin J. Evans wrote: >> >> On 08/09/10 21:24, Roode, Eric wrote: >>> Hello all, >>> >>> I am trying to implement error handling in our stored > procedures, > [...] >> >> Works fine for me (although possibly under