Skip Menu |

This queue is for tickets about the DBD-ODBC CPAN distribution.

Report information
The Basics
Id: 68510
Status: resolved
Priority: 0/
Queue: DBD-ODBC

People
Owner: Nobody in particular
Requestors: pedrinho [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 1.30_7



Subject: DBD::ODBC doesn't pass up warnings (RAISERROR with severity < 10)
Date: Fri, 27 May 2011 10:24:10 -0400
To: bug-DBD-ODBC [...] rt.cpan.org
From: "Peter C. Norton" <pedrinho [...] gmail.com>
We've noticed that low-severity errors (e.g. warnings) don't seem to trigger the error handler when using DBD::ODBC. I can't find documentation of a threshold or other thing that would control this. The same tests running under DBD::Sybase seem to trigger these warnings for us. Thanks, -Peter
On Fri May 27 10:24:18 2011, pedrinho@gmail.com wrote: Show quoted text
> We've noticed that low-severity errors (e.g. warnings) don't seem to
trigger Show quoted text
> the error handler when using DBD::ODBC. I can't find documentation of
a Show quoted text
> threshold or other thing that would control this. > > The same tests running under DBD::Sybase seem to trigger these
warnings for Show quoted text
> us. > > Thanks, > > -Peter
Which error handler are you using - DBD::ODBC or DBIs? Have you a small example I can look at? Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #68510] DBD::ODBC doesn't pass up warnings (RAISERROR with severity < 10)
Date: Fri, 27 May 2011 11:38:20 -0400
To: bug-DBD-ODBC [...] rt.cpan.org
From: "Peter C. Norton" <pedrinho [...] gmail.com>
I'm using DBD::ODBC's but I've tried the DBI handler - neither seems to fire (unless I'm doing it wrong. The DBI documentation for the handlers isn't as explicit as I'd like: use DBI; use Data::Dumper; my $sev = $ARGV[0]; if ($#ARGV == -1) { print "Usage: need a severity (number between 1 and 20)\n"; exit(2); } $dbh = DBI->connect("dbi:ODBC:DSN=FOOSERVER;APP=errorout", "foouser", "foopassword", {RaiseError=>1, HandleError=>sub {print Dumper(\@_) . "\n"}}); $dbh->do("raiserror('This is a test', $sev, 1)") This results in the following: $ perl ~/tmp/raiserror_simple.pl Usage: need a severity (number between 1 and 20) $ perl ~/tmp/raiserror_simple.pl 4 $ perl ~/tmp/raiserror_simple.pl 5 $ perl ~/tmp/raiserror_simple.pl 10 $ perl ~/tmp/raiserror_simple.pl 11 $VAR1 = [ 'DBD::ODBC::db do failed: [unixODBC][FreeTDS][SQL Server]This is a test (SQL-42000)', bless( {}, 'DBI::db' ), undef ]; The same results happen with the easysoft driver. Thanks, -Peter On Fri, May 27, 2011 at 11:13 AM, Martin J Evans via RT < bug-DBD-ODBC@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=68510 > > > On Fri May 27 10:24:18 2011, pedrinho@gmail.com wrote:
> > We've noticed that low-severity errors (e.g. warnings) don't seem to
> trigger
> > the error handler when using DBD::ODBC. I can't find documentation of
> a
> > threshold or other thing that would control this. > > > > The same tests running under DBD::Sybase seem to trigger these
> warnings for
> > us. > > > > Thanks, > > > > -Peter
> > Which error handler are you using - DBD::ODBC or DBIs? > > Have you a small example I can look at? > > Martin > -- > Martin J. Evans > Wetherby, UK >
On Fri May 27 11:38:30 2011, pedrinho@gmail.com wrote: Show quoted text
> I'm using DBD::ODBC's but I've tried the DBI handler - neither seems
to fire Show quoted text
> (unless I'm doing it wrong. The DBI documentation for the handlers
isn't as Show quoted text
> explicit as I'd like: > > use DBI; > use Data::Dumper; > my $sev = $ARGV[0]; > if ($#ARGV == -1) { > print "Usage: need a severity (number between 1 and 20)\n"; > exit(2); > } > $dbh = DBI->connect("dbi:ODBC:DSN=FOOSERVER;APP=errorout", "foouser", > "foopassword", > {RaiseError=>1, > HandleError=>sub {print Dumper(\@_) . "\n"}}); > $dbh->do("raiserror('This is a test', $sev, 1)") > > > This results in the following: > $ perl ~/tmp/raiserror_simple.pl > Usage: need a severity (number between 1 and 20) > $ perl ~/tmp/raiserror_simple.pl 4 > $ perl ~/tmp/raiserror_simple.pl 5 > $ perl ~/tmp/raiserror_simple.pl 10 > $ perl ~/tmp/raiserror_simple.pl 11 > $VAR1 = [ > 'DBD::ODBC::db do failed: [unixODBC][FreeTDS][SQL
Server]This is a Show quoted text
> test (SQL-42000)', > bless( {}, 'DBI::db' ), > undef > ]; > > The same results happen with the easysoft driver. > > Thanks, > > -Peter
Just a quick reply as I've not looked at it properly yet. In you example you are using DBI's error handler I see. In ODBC terms numbers less than 11 are SQL_SUCCESS_WITH_INFO returns. Numbers > 10 are errors and if I take your script as it is then for me it does not enter the error handler at all but the do fails with: DBD::ODBC::db do failed: [Microsoft][ODBC SQL Server Driver][SQL Server]This is a test (SQL-42000) at rt68510.t line 11. (See later). I'd expect the error handler to be called at least for errors but warnings are different in DBI. Also, for me, your code does not work as it seems to for you. I needed to set HandleError after connect. Hopefully, I can find some time to look at this over the weekend. Martin -- Martin J. Evans Wetherby, UK
On Fri May 27 14:45:04 2011, MJEVANS wrote: Show quoted text
> On Fri May 27 11:38:30 2011, pedrinho@gmail.com wrote:
> > I'm using DBD::ODBC's but I've tried the DBI handler - neither seems
> to fire
> > (unless I'm doing it wrong. The DBI documentation for the handlers
> isn't as
> > explicit as I'd like: > > > > use DBI; > > use Data::Dumper; > > my $sev = $ARGV[0]; > > if ($#ARGV == -1) { > > print "Usage: need a severity (number between 1 and 20)\n"; > > exit(2); > > } > > $dbh = DBI->connect("dbi:ODBC:DSN=FOOSERVER;APP=errorout", "foouser", > > "foopassword", > > {RaiseError=>1, > > HandleError=>sub {print Dumper(\@_) . "\n"}}); > > $dbh->do("raiserror('This is a test', $sev, 1)") > > > > > > This results in the following: > > $ perl ~/tmp/raiserror_simple.pl > > Usage: need a severity (number between 1 and 20) > > $ perl ~/tmp/raiserror_simple.pl 4 > > $ perl ~/tmp/raiserror_simple.pl 5 > > $ perl ~/tmp/raiserror_simple.pl 10 > > $ perl ~/tmp/raiserror_simple.pl 11 > > $VAR1 = [ > > 'DBD::ODBC::db do failed: [unixODBC][FreeTDS][SQL
> Server]This is a
> > test (SQL-42000)', > > bless( {}, 'DBI::db' ), > > undef > > ]; > > > > The same results happen with the easysoft driver. > > > > Thanks, > > > > -Peter
> > Just a quick reply as I've not looked at it properly yet. > > In you example you are using DBI's error handler I see. > > In ODBC terms numbers less than 11 are SQL_SUCCESS_WITH_INFO returns. > Numbers > 10 are errors and if I take your script as it is then for me > it does not enter the error handler at all but the do fails with: > > DBD::ODBC::db do failed: [Microsoft][ODBC SQL Server Driver][SQL > Server]This is a test (SQL-42000) at rt68510.t line 11. (See later). > > I'd expect the error handler to be called at least for errors but > warnings are different in DBI. > > Also, for me, your code does not work as it seems to for you. I needed > to set HandleError after connect. > > Hopefully, I can find some time to look at this over the weekend. > > Martin
It appears DBI does not call its error handler for warnings and when an ODBC call returns SQL_SUCCESS_WITH_INFO (which it does when raiseerror is passed < 11) that turns into a warning. Warnings are treated specially in DBI and you generally detect them by seeing if $h->err returns 0 (see http://search.cpan.org/~timb/DBI-1.616/DBI.pm#err). If you read http://search.cpan.org/~timb/DBI-1.616/DBI.pm#HandleError it says HandleError is called at the same point PrintError or RaiseError would be called so I'm not surprised DBI does not call the HandleError routine for warnings. You can change DBD::ODBC to cause the odbc_err_handler if you change the following code in dbdimp.c: Index: dbdimp.c =================================================================== --- dbdimp.c (revision 14879) +++ dbdimp.c (working copy) @@ -457,13 +457,15 @@ else { if (ret == SQL_NO_DATA) { rows = 0; - } else { - ret = SQLRowCount(stmt, &rows); - if (!SQL_SUCCEEDED(ret)) { - dbd_error( dbh, ret, "SQLRowCount failed" ); - rows = -1; - } + } else if (ret != SQL_SUCCESS) { + dbd_error2(dbh, ret, "Execute immediate success with info", + imp_dbh->henv, imp_dbh->hdbc, stmt ); } + ret = SQLRowCount(stmt, &rows); + if (!SQL_SUCCEEDED(ret)) { + dbd_error( dbh, ret, "SQLRowCount failed" ); + rows = -1; + } } ret = SQLFreeHandle(SQL_HANDLE_STMT,stmt); if (!SQL_SUCCEEDED(ret)) { but you'll see that although thay causes the ODBC error handler to be called (and assuming that handler returns 1) it still does not get in the DBI error handler as it is a warning. If you want to capture warnings in DBI you can use HandleSetErr - see http://search.cpan.org/~timb/DBI-1.616/DBI.pm#HandleSetErr which despite its name is called for warnings too. So, to summarise. It is possible DBD::ODBC should call its internal handler when SQLExecDirect returns SQL_SUCCESS_WITH_INFO but there is no precident in DBI to do so. If I changed it (above code) it may affect others who have odbc error handlers and do not expect to get informational/warning states. Whether I change it or not it will make no difference to DBI's HandleError as it is only used for errors and not warnings. Is raiseerror(<11) a warning - I'm afraid it is as SQLExecDirect will return SQL_SUCCESS_WITH_INFO which is success but there is something you might want to note. The most portable way of catching the warning is with HandleSetErr. If you have a problem with any of this it is probably best submitting a post to the dbi-users list where other DBD authors and Tim Bunce hang out as they may have an opinion as to whether something is wrong in DBD::ODBC or DBI. Martin -- Martin J. Evans Wetherby, UK
On Mon May 30 05:15:02 2011, MJEVANS wrote: Show quoted text
> On Fri May 27 14:45:04 2011, MJEVANS wrote:
> > On Fri May 27 11:38:30 2011, pedrinho@gmail.com wrote:
> > > I'm using DBD::ODBC's but I've tried the DBI handler - neither
seems Show quoted text
> > to fire
> > > (unless I'm doing it wrong. The DBI documentation for the
handlers Show quoted text
> > isn't as
> > > explicit as I'd like: > > > > > > use DBI; > > > use Data::Dumper; > > > my $sev = $ARGV[0]; > > > if ($#ARGV == -1) { > > > print "Usage: need a severity (number between 1 and 20)\n"; > > > exit(2); > > > } > > > $dbh = DBI->connect("dbi:ODBC:DSN=FOOSERVER;APP=errorout",
"foouser", Show quoted text
> > > "foopassword", > > > {RaiseError=>1, > > > HandleError=>sub {print Dumper(\@_) . "\n"}}); > > > $dbh->do("raiserror('This is a test', $sev, 1)") > > > > > > > > > This results in the following: > > > $ perl ~/tmp/raiserror_simple.pl > > > Usage: need a severity (number between 1 and 20) > > > $ perl ~/tmp/raiserror_simple.pl 4 > > > $ perl ~/tmp/raiserror_simple.pl 5 > > > $ perl ~/tmp/raiserror_simple.pl 10 > > > $ perl ~/tmp/raiserror_simple.pl 11 > > > $VAR1 = [ > > > 'DBD::ODBC::db do failed: [unixODBC][FreeTDS][SQL
> > Server]This is a
> > > test (SQL-42000)', > > > bless( {}, 'DBI::db' ), > > > undef > > > ]; > > > > > > The same results happen with the easysoft driver. > > > > > > Thanks, > > > > > > -Peter
> > > > Just a quick reply as I've not looked at it properly yet. > > > > In you example you are using DBI's error handler I see. > > > > In ODBC terms numbers less than 11 are SQL_SUCCESS_WITH_INFO
returns. Show quoted text
> > Numbers > 10 are errors and if I take your script as it is then for
me Show quoted text
> > it does not enter the error handler at all but the do fails with: > > > > DBD::ODBC::db do failed: [Microsoft][ODBC SQL Server Driver][SQL > > Server]This is a test (SQL-42000) at rt68510.t line 11. (See later). > > > > I'd expect the error handler to be called at least for errors but > > warnings are different in DBI. > > > > Also, for me, your code does not work as it seems to for you. I
needed Show quoted text
> > to set HandleError after connect. > > > > Hopefully, I can find some time to look at this over the weekend. > > > > Martin
> > It appears DBI does not call its error handler for warnings and when
an Show quoted text
> ODBC call returns SQL_SUCCESS_WITH_INFO (which it does when raiseerror > is passed < 11) that turns into a warning. Warnings are treated > specially in DBI and you generally detect them by seeing if $h->err > returns 0 (see http://search.cpan.org/~timb/DBI-1.616/DBI.pm#err). > > If you read http://search.cpan.org/~timb/DBI-1.616/DBI.pm#HandleError
it Show quoted text
> says HandleError is called at the same point PrintError or RaiseError > would be called so I'm not surprised DBI does not call the HandleError > routine for warnings. > > You can change DBD::ODBC to cause the odbc_err_handler if you change
the Show quoted text
> following code in dbdimp.c: > > Index: dbdimp.c > =================================================================== > --- dbdimp.c (revision 14879) > +++ dbdimp.c (working copy) > @@ -457,13 +457,15 @@ > else { > if (ret == SQL_NO_DATA) { > rows = 0; > - } else { > - ret = SQLRowCount(stmt, &rows); > - if (!SQL_SUCCEEDED(ret)) { > - dbd_error( dbh, ret, "SQLRowCount failed" ); > - rows = -1; > - } > + } else if (ret != SQL_SUCCESS) { > + dbd_error2(dbh, ret, "Execute immediate success with info", > + imp_dbh->henv, imp_dbh->hdbc, stmt ); > } > + ret = SQLRowCount(stmt, &rows); > + if (!SQL_SUCCEEDED(ret)) { > + dbd_error( dbh, ret, "SQLRowCount failed" ); > + rows = -1; > + } > } > ret = SQLFreeHandle(SQL_HANDLE_STMT,stmt); > if (!SQL_SUCCEEDED(ret)) { > > but you'll see that although thay causes the ODBC error handler to be > called (and assuming that handler returns 1) it still does not get in > the DBI error handler as it is a warning. > > If you want to capture warnings in DBI you can use HandleSetErr - see > http://search.cpan.org/~timb/DBI-1.616/DBI.pm#HandleSetErr which
despite Show quoted text
> its name is called for warnings too. > > So, to summarise. It is possible DBD::ODBC should call its internal > handler when SQLExecDirect returns SQL_SUCCESS_WITH_INFO but there is
no Show quoted text
> precident in DBI to do so. If I changed it (above code) it may affect > others who have odbc error handlers and do not expect to get > informational/warning states. Whether I change it or not it will make
no Show quoted text
> difference to DBI's HandleError as it is only used for errors and not > warnings. Is raiseerror(<11) a warning - I'm afraid it is as > SQLExecDirect will return SQL_SUCCESS_WITH_INFO which is success but > there is something you might want to note. The most portable way of > catching the warning is with HandleSetErr. If you have a problem with > any of this it is probably best submitting a post to the dbi-users
list Show quoted text
> where other DBD authors and Tim Bunce hang out as they may have an > opinion as to whether something is wrong in DBD::ODBC or DBI. > > Martin
I am happy to do more on this rt but I need some feedback as to what you are trying to achieve and what you think of my comments so far. If you have moved on and no longer want to pursue this rt could you let me know so I can close it. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #68510] DBD::ODBC doesn't pass up warnings (RAISERROR with severity < 10)
Date: Thu, 2 Jun 2011 16:11:34 -0400
To: bug-DBD-ODBC [...] rt.cpan.org
From: "Peter C. Norton" <pedrinho [...] gmail.com>
I think that everything you've said so far is reasonable. I'm encouraging our users to expect to discard messages with severity <= 10 since it seems that the default behavior in this infrastructure is to install an error handler that would discard these messages anyway. If you suspect that it would be generally useful to propagate these messages I'll help test that out and provide feedback as well. -Peter On Thu, Jun 2, 2011 at 9:05 AM, Martin J Evans via RT < bug-DBD-ODBC@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=68510 > > > On Mon May 30 05:15:02 2011, MJEVANS wrote:
> > On Fri May 27 14:45:04 2011, MJEVANS wrote:
> > > On Fri May 27 11:38:30 2011, pedrinho@gmail.com wrote:
> > > > I'm using DBD::ODBC's but I've tried the DBI handler - neither
> seems
> > > to fire
> > > > (unless I'm doing it wrong. The DBI documentation for the
> handlers
> > > isn't as
> > > > explicit as I'd like: > > > > > > > > use DBI; > > > > use Data::Dumper; > > > > my $sev = $ARGV[0]; > > > > if ($#ARGV == -1) { > > > > print "Usage: need a severity (number between 1 and 20)\n"; > > > > exit(2); > > > > } > > > > $dbh = DBI->connect("dbi:ODBC:DSN=FOOSERVER;APP=errorout",
> "foouser",
> > > > "foopassword", > > > > {RaiseError=>1, > > > > HandleError=>sub {print Dumper(\@_) . "\n"}}); > > > > $dbh->do("raiserror('This is a test', $sev, 1)") > > > > > > > > > > > > This results in the following: > > > > $ perl ~/tmp/raiserror_simple.pl > > > > Usage: need a severity (number between 1 and 20) > > > > $ perl ~/tmp/raiserror_simple.pl 4 > > > > $ perl ~/tmp/raiserror_simple.pl 5 > > > > $ perl ~/tmp/raiserror_simple.pl 10 > > > > $ perl ~/tmp/raiserror_simple.pl 11 > > > > $VAR1 = [ > > > > 'DBD::ODBC::db do failed: [unixODBC][FreeTDS][SQL
> > > Server]This is a
> > > > test (SQL-42000)', > > > > bless( {}, 'DBI::db' ), > > > > undef > > > > ]; > > > > > > > > The same results happen with the easysoft driver. > > > > > > > > Thanks, > > > > > > > > -Peter
> > > > > > Just a quick reply as I've not looked at it properly yet. > > > > > > In you example you are using DBI's error handler I see. > > > > > > In ODBC terms numbers less than 11 are SQL_SUCCESS_WITH_INFO
> returns.
> > > Numbers > 10 are errors and if I take your script as it is then for
> me
> > > it does not enter the error handler at all but the do fails with: > > > > > > DBD::ODBC::db do failed: [Microsoft][ODBC SQL Server Driver][SQL > > > Server]This is a test (SQL-42000) at rt68510.t line 11. (See later). > > > > > > I'd expect the error handler to be called at least for errors but > > > warnings are different in DBI. > > > > > > Also, for me, your code does not work as it seems to for you. I
> needed
> > > to set HandleError after connect. > > > > > > Hopefully, I can find some time to look at this over the weekend. > > > > > > Martin
> > > > It appears DBI does not call its error handler for warnings and when
> an
> > ODBC call returns SQL_SUCCESS_WITH_INFO (which it does when raiseerror > > is passed < 11) that turns into a warning. Warnings are treated > > specially in DBI and you generally detect them by seeing if $h->err > > returns 0 (see http://search.cpan.org/~timb/DBI-1.616/DBI.pm#err). > > > > If you read http://search.cpan.org/~timb/DBI-1.616/DBI.pm#HandleError
> it
> > says HandleError is called at the same point PrintError or RaiseError > > would be called so I'm not surprised DBI does not call the HandleError > > routine for warnings. > > > > You can change DBD::ODBC to cause the odbc_err_handler if you change
> the
> > following code in dbdimp.c: > > > > Index: dbdimp.c > > =================================================================== > > --- dbdimp.c (revision 14879) > > +++ dbdimp.c (working copy) > > @@ -457,13 +457,15 @@ > > else { > > if (ret == SQL_NO_DATA) { > > rows = 0; > > - } else { > > - ret = SQLRowCount(stmt, &rows); > > - if (!SQL_SUCCEEDED(ret)) { > > - dbd_error( dbh, ret, "SQLRowCount failed" ); > > - rows = -1; > > - } > > + } else if (ret != SQL_SUCCESS) { > > + dbd_error2(dbh, ret, "Execute immediate success with info", > > + imp_dbh->henv, imp_dbh->hdbc, stmt ); > > } > > + ret = SQLRowCount(stmt, &rows); > > + if (!SQL_SUCCEEDED(ret)) { > > + dbd_error( dbh, ret, "SQLRowCount failed" ); > > + rows = -1; > > + } > > } > > ret = SQLFreeHandle(SQL_HANDLE_STMT,stmt); > > if (!SQL_SUCCEEDED(ret)) { > > > > but you'll see that although thay causes the ODBC error handler to be > > called (and assuming that handler returns 1) it still does not get in > > the DBI error handler as it is a warning. > > > > If you want to capture warnings in DBI you can use HandleSetErr - see > > http://search.cpan.org/~timb/DBI-1.616/DBI.pm#HandleSetErr which
> despite
> > its name is called for warnings too. > > > > So, to summarise. It is possible DBD::ODBC should call its internal > > handler when SQLExecDirect returns SQL_SUCCESS_WITH_INFO but there is
> no
> > precident in DBI to do so. If I changed it (above code) it may affect > > others who have odbc error handlers and do not expect to get > > informational/warning states. Whether I change it or not it will make
> no
> > difference to DBI's HandleError as it is only used for errors and not > > warnings. Is raiseerror(<11) a warning - I'm afraid it is as > > SQLExecDirect will return SQL_SUCCESS_WITH_INFO which is success but > > there is something you might want to note. The most portable way of > > catching the warning is with HandleSetErr. If you have a problem with > > any of this it is probably best submitting a post to the dbi-users
> list
> > where other DBD authors and Tim Bunce hang out as they may have an > > opinion as to whether something is wrong in DBD::ODBC or DBI. > > > > Martin
> > I am happy to do more on this rt but I need some feedback as to what you > are trying to achieve and what you think of my comments so far. > > If you have moved on and no longer want to pursue this rt could you let > me know so I can close it. > > Martin > -- > Martin J. Evans > Wetherby, UK >
On Thu Jun 02 16:11:44 2011, pedrinho@gmail.com wrote: Show quoted text
> I think that everything you've said so far is reasonable. I'm encouraging > our users to expect to discard messages with severity <= 10 since it seems > that the default behavior in this infrastructure is to install an error > handler that would discard these messages anyway. > > If you suspect that it would be generally useful to propagate these
messages Show quoted text
> I'll help test that out and provide feedback as well. > > -Peter
Did you try the patch I included in this RT? Looking at this again, my reservation was that it would change the behaviour of DBD::ODBC to add that patch. However, some other warnings already go to the odbc_err_handler so at best it is inconsistent and I'm thinking the bug is really that DBD::ODBC does not report warnings from SQLExecute/SQLExecDirect full stop. So, I think I'm going to apply the patch in this RT and would be interested if you could try it out with the odbc_err_handler then I could make it permanent and do another development release. Interestingly someone else just posted to the dbi-users list regarding get_info and migration from DBD::Sybase to DBD::ODBC - perhaps that was you or a colleague - http://www.nntp.perl.org/group/perl.dbi.users/2011/06/msg35864.html. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #68510] DBD::ODBC doesn't pass up warnings (RAISERROR with severity < 10)
Date: Fri, 3 Jun 2011 14:48:57 -0400
To: bug-DBD-ODBC [...] rt.cpan.org
From: "Peter C. Norton" <pedrinho [...] gmail.com>
I'll try this out next week. The other request is a funny coincidence. He's a friend who I know is on a parallel track at his work. -Peter On Fri, Jun 3, 2011 at 1:51 PM, Martin J Evans via RT < bug-DBD-ODBC@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=68510 > > > On Thu Jun 02 16:11:44 2011, pedrinho@gmail.com wrote:
> > I think that everything you've said so far is reasonable. I'm
> encouraging
> > our users to expect to discard messages with severity <= 10 since it
> seems
> > that the default behavior in this infrastructure is to install an error > > handler that would discard these messages anyway. > > > > If you suspect that it would be generally useful to propagate these
> messages
> > I'll help test that out and provide feedback as well. > > > > -Peter
> > Did you try the patch I included in this RT? > > Looking at this again, my reservation was that it would change the > behaviour of DBD::ODBC to add that patch. However, some other warnings > already go to the odbc_err_handler so at best it is inconsistent and I'm > thinking the bug is really that DBD::ODBC does not report warnings from > SQLExecute/SQLExecDirect full stop. So, I think I'm going to apply the > patch in this RT and would be interested if you could try it out with > the odbc_err_handler then I could make it permanent and do another > development release. > > Interestingly someone else just posted to the dbi-users list regarding > get_info and migration from DBD::Sybase to DBD::ODBC - perhaps that was > you or a colleague - > http://www.nntp.perl.org/group/perl.dbi.users/2011/06/msg35864.html. > > > Martin > -- > Martin J. Evans > Wetherby, UK >
Subject: Re: [rt.cpan.org #68510] DBD::ODBC doesn't pass up warnings (RAISERROR with severity < 10)
Date: Mon, 6 Jun 2011 12:07:09 -0400
To: bug-DBD-ODBC [...] rt.cpan.org
From: "Peter C. Norton" <pedrinho [...] gmail.com>
The patch does cause errors to be raised into the odbc_err_handler (tesed on SQL Server 2008R2 with raiserror('message', $sev, 1)). I'm not clear on how this should interact with DBI's HandleError, since with this patch it seems to remain silent until the severity goes beyond 10. -Peter On Fri, Jun 3, 2011 at 1:51 PM, Martin J Evans via RT < bug-DBD-ODBC@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=68510 > > > On Thu Jun 02 16:11:44 2011, pedrinho@gmail.com wrote:
> > I think that everything you've said so far is reasonable. I'm
> encouraging
> > our users to expect to discard messages with severity <= 10 since it
> seems
> > that the default behavior in this infrastructure is to install an error > > handler that would discard these messages anyway. > > > > If you suspect that it would be generally useful to propagate these
> messages
> > I'll help test that out and provide feedback as well. > > > > -Peter
> > Did you try the patch I included in this RT? > > Looking at this again, my reservation was that it would change the > behaviour of DBD::ODBC to add that patch. However, some other warnings > already go to the odbc_err_handler so at best it is inconsistent and I'm > thinking the bug is really that DBD::ODBC does not report warnings from > SQLExecute/SQLExecDirect full stop. So, I think I'm going to apply the > patch in this RT and would be interested if you could try it out with > the odbc_err_handler then I could make it permanent and do another > development release. > > Interestingly someone else just posted to the dbi-users list regarding > get_info and migration from DBD::Sybase to DBD::ODBC - perhaps that was > you or a colleague - > http://www.nntp.perl.org/group/perl.dbi.users/2011/06/msg35864.html. > > > Martin > -- > Martin J. Evans > Wetherby, UK >
Subject: Re: [rt.cpan.org #68510] DBD::ODBC doesn't pass up warnings (RAISERROR with severity < 10)
Date: Mon, 6 Jun 2011 14:16:38 -0400
To: bug-DBD-ODBC [...] rt.cpan.org
From: "Peter C. Norton" <pedrinho [...] gmail.com>
Something interesting in the Sybase->SQL Server transition: $dbh->do("use tempdb; set statistics io on select top 1 * from sys.objects"); Doesn't do what we'd expect, which is to return statistics info to the message handler. Instead this is the output via the freetds odbc driver: $ perl ~/tmp/causerr.pl $VAR1 = [ '01000', '[unixODBC][FreeTDS][SQL Server]Changed database context to \'tempdb\'.', 5701 ]; However this works for Sybase, which makes me think that SQL Server is simply not providing a message with the info that isn't being returned. Any idea whether this gets signaled somehow? Thanks, -Peter On Mon, Jun 6, 2011 at 12:07 PM, Peter C. Norton <pedrinho@gmail.com> wrote: Show quoted text
> The patch does cause errors to be raised into the odbc_err_handler (tesed > on SQL Server 2008R2 with raiserror('message', $sev, 1)). > > I'm not clear on how this should interact with DBI's HandleError, since > with this patch it seems to remain silent until the severity goes beyond 10. > > -Peter > > > On Fri, Jun 3, 2011 at 1:51 PM, Martin J Evans via RT < > bug-DBD-ODBC@rt.cpan.org> wrote: >
>> <URL: https://rt.cpan.org/Ticket/Display.html?id=68510 > >> >> On Thu Jun 02 16:11:44 2011, pedrinho@gmail.com wrote:
>> > I think that everything you've said so far is reasonable. I'm
>> encouraging
>> > our users to expect to discard messages with severity <= 10 since it
>> seems
>> > that the default behavior in this infrastructure is to install an error >> > handler that would discard these messages anyway. >> > >> > If you suspect that it would be generally useful to propagate these
>> messages
>> > I'll help test that out and provide feedback as well. >> > >> > -Peter
>> >> Did you try the patch I included in this RT? >> >> Looking at this again, my reservation was that it would change the >> behaviour of DBD::ODBC to add that patch. However, some other warnings >> already go to the odbc_err_handler so at best it is inconsistent and I'm >> thinking the bug is really that DBD::ODBC does not report warnings from >> SQLExecute/SQLExecDirect full stop. So, I think I'm going to apply the >> patch in this RT and would be interested if you could try it out with >> the odbc_err_handler then I could make it permanent and do another >> development release. >> >> Interestingly someone else just posted to the dbi-users list regarding >> get_info and migration from DBD::Sybase to DBD::ODBC - perhaps that was >> you or a colleague - >> http://www.nntp.perl.org/group/perl.dbi.users/2011/06/msg35864.html. >> >> >> Martin >> -- >> Martin J. Evans >> Wetherby, UK >>
> >
On Mon Jun 06 12:07:19 2011, pedrinho@gmail.com wrote: Show quoted text
> The patch does cause errors to be raised into the odbc_err_handler
(tesed on Show quoted text
> SQL Server 2008R2 with raiserror('message', $sev, 1)). > > I'm not clear on how this should interact with DBI's HandleError,
since with Show quoted text
> this patch it seems to remain silent until the severity goes beyond 10. > > -Peter
Thanks Peter. DBD::ODBC's odbc_err_handler differs from DBI's. DBD::ODBC's odbc_err_handler predates DBI's but was never removed because people still use it. DBD::ODBC's handler is called for errors (SQL_ERROR etc from ODBC calls which are raised as DBI errors) AND warnings (SQL_SUCCESS_WITH_INFO from ODBC calls which are raised as DBI warnings since that is what DBI mandates) which differs from DBI's handler which is only called for errors. All the patch does is capture another warning that was not caught before (which is why I had less of a problem with it). Possibly your problem seeing this is that you are using raiseERROR (which sounds like errors) but in fact error numbers passed to raiseerror of < 11 cause the ODBC call to return SQL_SUCCESS_WITH_INFO which is translated to a warning in DBI terms but still causes DBD::ODBC's error handler to be called. Martin -- Martin J. Evans Wetherby, UK
On Mon Jun 06 14:16:48 2011, pedrinho@gmail.com wrote: Show quoted text
> Something interesting in the Sybase->SQL Server transition: > > $dbh->do("use tempdb; set statistics io on select top 1 * from > sys.objects"); > > Doesn't do what we'd expect, which is to return statistics info to the > message handler. Instead this is the output via the freetds odbc > driver: > > $ perl ~/tmp/causerr.pl > $VAR1 = [ > '01000', > '[unixODBC][FreeTDS][SQL Server]Changed database context to > \'tempdb\'.', > 5701 > ]; > > However this works for Sybase, which makes me think that SQL Server is > simply not providing a message with the info that isn't being > returned. Any > idea whether this gets signaled somehow? > > Thanks, > > -Peter
I'd need to see a trace of this to see what is happening. set and export DBI_TRACE=15=x.log and run the code above then attach the x.log file to this RT and I'll take a look. Martin -- Martin J. Evans Wetherby, UK
On Mon Jun 06 14:25:59 2011, MJEVANS wrote: Show quoted text
> On Mon Jun 06 14:16:48 2011, pedrinho@gmail.com wrote:
> > Something interesting in the Sybase->SQL Server transition: > > > > $dbh->do("use tempdb; set statistics io on select top 1 * from > > sys.objects"); > > > > Doesn't do what we'd expect, which is to return statistics info to the > > message handler. Instead this is the output via the freetds odbc > > driver: > > > > $ perl ~/tmp/causerr.pl > > $VAR1 = [ > > '01000', > > '[unixODBC][FreeTDS][SQL Server]Changed database context to > > \'tempdb\'.', > > 5701 > > ]; > > > > However this works for Sybase, which makes me think that SQL Server is > > simply not providing a message with the info that isn't being > > returned. Any > > idea whether this gets signaled somehow? > > > > Thanks, > > > > -Peter
> > I'd need to see a trace of this to see what is happening. set and export > DBI_TRACE=15=x.log and run the code above then attach the x.log file to > this RT and I'll take a look. > > Martin
Actually, I just tried it with the MS SQL Server ODBC driver and it exhibits the same as freeTDS. The "set statistics io on select top 1 * from sys.objects" does not generate SQL_SUCCESS_WITH_INFO. You can test this yourself by separating the use from the set in 2 different dos. I will need to play with this more to see why - it may be normal behaviour. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #68510] DBD::ODBC doesn't pass up warnings (RAISERROR with severity < 10)
Date: Mon, 6 Jun 2011 15:28:13 -0400
To: bug-DBD-ODBC [...] rt.cpan.org
From: "Peter C. Norton" <pedrinho [...] gmail.com>
Yes, the "use tempdb" was only there to elicit a message for comparison. It's possible that neither does "$dbh->do('sp_help [sys.objects]')" for instance, which does elicit a message on Sybase, though I don't know if this is defined behavior or not. If you don't need it, I'll skip the DBI trace, but I'd be interested in whatever you find regarding the behavior of SQL Server and whether it's expected that this will behave so differently. Thanks, -Peter On Mon, Jun 6, 2011 at 2:44 PM, Martin J Evans via RT < bug-DBD-ODBC@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=68510 > > > On Mon Jun 06 14:25:59 2011, MJEVANS wrote:
> > On Mon Jun 06 14:16:48 2011, pedrinho@gmail.com wrote:
> > > Something interesting in the Sybase->SQL Server transition: > > > > > > $dbh->do("use tempdb; set statistics io on select top 1 * from > > > sys.objects"); > > > > > > Doesn't do what we'd expect, which is to return statistics info to the > > > message handler. Instead this is the output via the freetds odbc > > > driver: > > > > > > $ perl ~/tmp/causerr.pl > > > $VAR1 = [ > > > '01000', > > > '[unixODBC][FreeTDS][SQL Server]Changed database context to > > > \'tempdb\'.', > > > 5701 > > > ]; > > > > > > However this works for Sybase, which makes me think that SQL Server is > > > simply not providing a message with the info that isn't being > > > returned. Any > > > idea whether this gets signaled somehow? > > > > > > Thanks, > > > > > > -Peter
> > > > I'd need to see a trace of this to see what is happening. set and export > > DBI_TRACE=15=x.log and run the code above then attach the x.log file to > > this RT and I'll take a look. > > > > Martin
> > Actually, I just tried it with the MS SQL Server ODBC driver and it > exhibits the same as freeTDS. > > The "set statistics io on select top 1 * from sys.objects" does not > generate SQL_SUCCESS_WITH_INFO. You can test this yourself by separating > the use from the set in 2 different dos. > > I will need to play with this more to see why - it may be normal behaviour. > > Martin > -- > Martin J. Evans > Wetherby, UK >
Subject: Re: [rt.cpan.org #68510] DBD::ODBC doesn't pass up warnings (RAISERROR with severity < 10)
Date: Wed, 8 Jun 2011 15:36:27 -0400
To: bug-DBD-ODBC [...] rt.cpan.org
From: "Peter C. Norton" <pedrinho [...] gmail.com>
This is strange. So looking at the dbdimp.c, do() eventually calls SQLExecDirect, which returns 0 when I run a select with the "set statistics io on ...", but if it's prepared and executed via selectall_arrayref() it goes through a completely different code path. I can't really determine via looking at DBI and DBD::ODBC source code exactly what the code path is for selectall_arrayref() when called like this: my $ref = $dbh->selectall_arrayref("set statistics io on select top 1 * from sysusers"); but doing this does cause the odbc_err_handler to receive the messages, apparently SQL_SUCCESS_WITH_INFO, I guess via dbd_st_fetch(). I suppose this makes sense, but the data doesn't come out if I only do a prepare()+execute()+fetch() all available rows - only then does the trace show: <- fetchrow_array= ( '0' '0' 'public' '....... ....«3.v#.v@.Ò©.2kúU' undef 'Apr 08 2003 09:10AM' 'Jul 09 2008 04:19PM' '1' undef '0' undef '0' '0' '0' '0' '0' '0' '0' '1' '0' ) [20 items] row1 at /u/nortonp/tmp/ statistics_in_the_resultset.pl line 14 -> fetchrow_array for DBD::ODBC::st (DBI::st=HASH(0x720010)~0x71ffb0) thr#411400 SQLFetch rc 100 !!dbd_error2(err_rc=1, what=st_fetch/SQLMoreResults, handles=(7c18d0,7c1f20,7cff40) !SQLError(7c18d0,7c1f20,7cff40) = (01000, 3615, [unixODBC] ... etc... so no errors are signaled until the results are fetched and 100/SQL_NO_DATA/SQL_NO_DATA_FOUND is returned and SQLMoreResults at around line 2833 in my dbdimp.c, followed by another check where SQL_SUCCESS_WITH_INFO seems to finally be returned. So it seems like via both easysoft and freetds odbc drivers SQL Server is simply returning SQL_SUCCEEDED and only if results are SQLFetch()'d and SQL_NO_DATA is encountered will the error message be seen. Does this match what you're seeing? -Peter On Mon, Jun 6, 2011 at 3:28 PM, Peter C. Norton <pedrinho@gmail.com> wrote: Show quoted text
> Yes, the "use tempdb" was only there to elicit a message for comparison. > It's possible that neither does "$dbh->do('sp_help [sys.objects]')" for > instance, which does elicit a message on Sybase, though I don't know if this > is defined behavior or not. > > If you don't need it, I'll skip the DBI trace, but I'd be interested in > whatever you find regarding the behavior of SQL Server and whether it's > expected that this will behave so differently. > > Thanks, > > -Peter > > > On Mon, Jun 6, 2011 at 2:44 PM, Martin J Evans via RT < > bug-DBD-ODBC@rt.cpan.org> wrote: >
>> <URL: https://rt.cpan.org/Ticket/Display.html?id=68510 > >> >> On Mon Jun 06 14:25:59 2011, MJEVANS wrote:
>> > On Mon Jun 06 14:16:48 2011, pedrinho@gmail.com wrote:
>> > > Something interesting in the Sybase->SQL Server transition: >> > > >> > > $dbh->do("use tempdb; set statistics io on select top 1 * from >> > > sys.objects"); >> > > >> > > Doesn't do what we'd expect, which is to return statistics info to the >> > > message handler. Instead this is the output via the freetds odbc >> > > driver: >> > > >> > > $ perl ~/tmp/causerr.pl >> > > $VAR1 = [ >> > > '01000', >> > > '[unixODBC][FreeTDS][SQL Server]Changed database context to >> > > \'tempdb\'.', >> > > 5701 >> > > ]; >> > > >> > > However this works for Sybase, which makes me think that SQL Server is >> > > simply not providing a message with the info that isn't being >> > > returned. Any >> > > idea whether this gets signaled somehow? >> > > >> > > Thanks, >> > > >> > > -Peter
>> > >> > I'd need to see a trace of this to see what is happening. set and export >> > DBI_TRACE=15=x.log and run the code above then attach the x.log file to >> > this RT and I'll take a look. >> > >> > Martin
>> >> Actually, I just tried it with the MS SQL Server ODBC driver and it >> exhibits the same as freeTDS. >> >> The "set statistics io on select top 1 * from sys.objects" does not >> generate SQL_SUCCESS_WITH_INFO. You can test this yourself by separating >> the use from the set in 2 different dos. >> >> I will need to play with this more to see why - it may be normal >> behaviour. >> >> Martin >> -- >> Martin J. Evans >> Wetherby, UK >>
> >
Subject: Re: [rt.cpan.org #68510] DBD::ODBC doesn't pass up warnings (RAISERROR with severity < 10)
Date: Wed, 8 Jun 2011 19:28:50 -0400
To: bug-DBD-ODBC [...] rt.cpan.org
From: "Peter C. Norton" <pedrinho [...] gmail.com>
And, the last weirdness: back to your remarking on the inconsistency of the passing of warnings via the error handler, what can be done to eliminate that? Is there a proper way to pass this to the DBI warning string, or to attach a property to the message so that warnings can be distinguished from errors? -Peter On Wed, Jun 8, 2011 at 3:36 PM, Peter C. Norton <pedrinho@gmail.com> wrote: Show quoted text
> This is strange. So looking at the dbdimp.c, do() eventually calls > SQLExecDirect, which returns 0 when I run a select with the "set statistics > io on ...", but if it's prepared and executed via selectall_arrayref() it > goes through a completely different code path. > > I can't really determine via looking at DBI and DBD::ODBC source code > exactly what the code path is for selectall_arrayref() when called like > this: > > my $ref = $dbh->selectall_arrayref("set statistics io on select top 1 * > from sysusers"); > > but doing this does cause the odbc_err_handler to receive the messages, > apparently SQL_SUCCESS_WITH_INFO, I guess via dbd_st_fetch(). > > I suppose this makes sense, but the data doesn't come out if I only do a > prepare()+execute()+fetch() all available rows - only then does the trace > show: > > <- fetchrow_array= ( '0' '0' 'public' '....... ....«3.v#.v@.Ò©.2kúU' > undef 'Apr 08 2003 09:10AM' 'Jul 09 2008 04:19PM' '1' undef '0' undef '0' > '0' '0' '0' '0' '0' '0' '1' '0' ) [20 items] row1 at /u/nortonp/tmp/ > statistics_in_the_resultset.pl line 14 > -> fetchrow_array for DBD::ODBC::st (DBI::st=HASH(0x720010)~0x71ffb0) > thr#411400 > SQLFetch rc 100 > !!dbd_error2(err_rc=1, what=st_fetch/SQLMoreResults, > handles=(7c18d0,7c1f20,7cff40) > !SQLError(7c18d0,7c1f20,7cff40) = (01000, 3615, [unixODBC] ... > > etc... so no errors are signaled until the results are fetched and > 100/SQL_NO_DATA/SQL_NO_DATA_FOUND is returned and SQLMoreResults at around > line 2833 in my dbdimp.c, followed by another check where > SQL_SUCCESS_WITH_INFO seems to finally be returned. > > So it seems like via both easysoft and freetds odbc drivers SQL Server is > simply returning SQL_SUCCEEDED and only if results are SQLFetch()'d and > SQL_NO_DATA is encountered will the error message be seen. > > Does this match what you're seeing? > > -Peter > > > > > On Mon, Jun 6, 2011 at 3:28 PM, Peter C. Norton <pedrinho@gmail.com>wrote: >
>> Yes, the "use tempdb" was only there to elicit a message for comparison. >> It's possible that neither does "$dbh->do('sp_help [sys.objects]')" for >> instance, which does elicit a message on Sybase, though I don't know if this >> is defined behavior or not. >> >> If you don't need it, I'll skip the DBI trace, but I'd be interested in >> whatever you find regarding the behavior of SQL Server and whether it's >> expected that this will behave so differently. >> >> Thanks, >> >> -Peter >> >> >> On Mon, Jun 6, 2011 at 2:44 PM, Martin J Evans via RT < >> bug-DBD-ODBC@rt.cpan.org> wrote: >>
>>> <URL: https://rt.cpan.org/Ticket/Display.html?id=68510 > >>> >>> On Mon Jun 06 14:25:59 2011, MJEVANS wrote:
>>> > On Mon Jun 06 14:16:48 2011, pedrinho@gmail.com wrote:
>>> > > Something interesting in the Sybase->SQL Server transition: >>> > > >>> > > $dbh->do("use tempdb; set statistics io on select top 1 * from >>> > > sys.objects"); >>> > > >>> > > Doesn't do what we'd expect, which is to return statistics info to
>>> the
>>> > > message handler. Instead this is the output via the freetds odbc >>> > > driver: >>> > > >>> > > $ perl ~/tmp/causerr.pl >>> > > $VAR1 = [ >>> > > '01000', >>> > > '[unixODBC][FreeTDS][SQL Server]Changed database context to >>> > > \'tempdb\'.', >>> > > 5701 >>> > > ]; >>> > > >>> > > However this works for Sybase, which makes me think that SQL Server
>>> is
>>> > > simply not providing a message with the info that isn't being >>> > > returned. Any >>> > > idea whether this gets signaled somehow? >>> > > >>> > > Thanks, >>> > > >>> > > -Peter
>>> > >>> > I'd need to see a trace of this to see what is happening. set and
>>> export
>>> > DBI_TRACE=15=x.log and run the code above then attach the x.log file to >>> > this RT and I'll take a look. >>> > >>> > Martin
>>> >>> Actually, I just tried it with the MS SQL Server ODBC driver and it >>> exhibits the same as freeTDS. >>> >>> The "set statistics io on select top 1 * from sys.objects" does not >>> generate SQL_SUCCESS_WITH_INFO. You can test this yourself by separating >>> the use from the set in 2 different dos. >>> >>> I will need to play with this more to see why - it may be normal >>> behaviour. >>> >>> Martin >>> -- >>> Martin J. Evans >>> Wetherby, UK >>>
>> >>
>
On Wed Jun 08 19:29:02 2011, pedrinho@gmail.com wrote: Show quoted text
> And, the last weirdness: back to your remarking on the inconsistency > of the > passing of warnings via the error handler, what can be done to > eliminate > that? Is there a proper way to pass this to the DBI warning string, > or to > attach a property to the message so that warnings can be distinguished > from > errors? > > -Peter >
The only inconsistency I see is that DBI's error handler only gets called for errors and DBD::ODBC's gets called for warnings and errors - it has been like since before I took over maintainership of DBD::ODBC. DBI already defines a mechanism for drivers to report warnings or errors with http://search.cpan.org/~timb/DBI-1.616/DBI.pm#set_err. However, this should not be confused with http://search.cpan.org/~timb/DBI- 1.616/DBI.pm#Warn. You can catch warnings with http://search.cpan.org/~timb/DBI-1.616/DBI.pm#PrintWarn and a $SIG{__WARN__} handler. I'm not sure exactly what you are trying to achieve. I strongly suggest you are better posting your situation on the dbi-users list as there are a lot more people with more knowledge than me on it. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #68510] DBD::ODBC doesn't pass up warnings (RAISERROR with severity < 10)
Date: Thu, 9 Jun 2011 04:19:55 -0400
To: bug-DBD-ODBC [...] rt.cpan.org
From: "Peter C. Norton" <pedrinho [...] gmail.com>
Maybe I'm saying this poorly, the inconsistency (maybe a poor choice of words) is from the observation that without some severity info it's not possible to determine in the error handler whether a message is an error or a warning. The dbi warning handler/printer doesn't seem to be involved at this point so I'm wondering how to get messages stemming from SQL_SUCCESS_WITH_INFO there. Thanks, -Peter On Jun 9, 2011 3:57 AM, "Martin J Evans via RT" <bug-DBD-ODBC@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=68510 > > > On Wed Jun 08 19:29:02 2011, pedrinho@gmail.com wrote:
>> And, the last weirdness: back to your remarking on the inconsistency >> of the >> passing of warnings via the error handler, what can be done to >> eliminate >> that? Is there a proper way to pass this to the DBI warning string, >> or to >> attach a property to the message so that warnings can be distinguished >> from >> errors? >> >> -Peter >>
> > The only inconsistency I see is that DBI's error handler only gets > called for errors and DBD::ODBC's gets called for warnings and errors - > it has been like since before I took over maintainership of DBD::ODBC. > DBI already defines a mechanism for drivers to report warnings or errors > with http://search.cpan.org/~timb/DBI-1.616/DBI.pm#set_err. However, > this should not be confused with http://search.cpan.org/~timb/DBI- > 1.616/DBI.pm#Warn. You can catch warnings with > http://search.cpan.org/~timb/DBI-1.616/DBI.pm#PrintWarn and a > $SIG{__WARN__} handler. > > I'm not sure exactly what you are trying to achieve. I strongly suggest > you are better posting your situation on the dbi-users list as there are > a lot more people with more knowledge than me on it. > > Martin > -- > Martin J. Evans > Wetherby, UK
On Thu Jun 09 04:20:10 2011, pedrinho@gmail.com wrote: Show quoted text
> Maybe I'm saying this poorly, the inconsistency (maybe a poor choice of > words) is from the observation that without some severity info it's not > possible to determine in the error handler whether a message is an
error or Show quoted text
> a warning. The dbi warning handler/printer doesn't seem to be involved at > this point so I'm wondering how to get messages stemming from > SQL_SUCCESS_WITH_INFO there. > > Thanks, > > -Peter
Peter, are you are irc or can use irc so I could talk to you about this more directly? I hang about on irc.perl.org on the #dbi channel. Martin -- Martin J. Evans Wetherby, UK