I may being really daft here but I can't see why changing
ShowErrorStatement should change what happens here (unless
it is consuming errors before the error handler is called).

bash-2.05$ perl -MDBI -e 'print "$DBI::VERSION\n";'
1.48
bash-2.05$ perl --version
This is perl, v5.8.7 built for i686-linux

Driver is MyODBC 3.51.12 but it reports
bash-2.05$ perl -M'DBD::mysql' -e 'print "$DBD::mysql::VERSION\n";'
3.0002

use strict;
use warnings;
use DBI;
use Carp;

my $dbh = DBI->connect("dbi:ODBC:xxx", "yyy", "zzz",
{RaiseError => 1, PrintError => 1, ShowErrorStatement => 0,
HandleError => \&error_trap});
my $sth = $dbh->prepare("sselect * from bench_char");
$sth->execute;
sub error_trap
{
my ($msg, $h, $ret) = [at] _;

print "Type=", $h->{Type}, "\n",
"SQL=", $h->{Statement}, "\n",
"Error=", $h->errstr, "\n";
confess("confess");
return 1;
}

shows:

bash-2.05$ perl x.pl
Type=st
SQL=sselect * from bench_char
Error=[unixODBC][MySQL][ODBC 3.51 Driver][mysqld-5.0.15-log]You have an
error in your SQL syntax; check the manual that corresponds to your
MySQL server version for the right syntax to use near
'sselect * from bench_char' at line 1
(SQL-23000)(DBD: st_execute/SQLExecute err=-1)
confess at x.pl line 21
main::error_trap('DBD::ODBC::st execute failed:
[unixODBC][MySQL][ODBC 3.51 Dri...',
'DBI::st=HASH(0x8248b04)', 'undef') called at x.pl line 12

which is what I'd expect BUT simply changing ShowErrorStatement => 1 produces:

bash-2.05$ perl x.pl
Describe failed during DBI::st=HASH(0x8248af8)->FETCH(ParamValues,0)
at x.pl line 12.
Type=st
SQL=sselect * from bench_char
Error=[unixODBC][MySQL][ODBC 3.51 Driver][mysqld-5.0.15-log]
Invalid cursor state (SQL-24000)(DBD: dbd_describe/SQLNumResultCols err=-1)
confess at x.pl line 21
main::error_trap('DBD::ODBC::st execute failed:
[unixODBC][MySQL][ODBC 3.51 Dri...', 'DBI::st=HASH(0x8248b04)',
'undef') called at x.pl line 12

It would appear setting ShowErrorStatement:

1. causes the code to run further before stopping
2. loses an error

Any ideas?

Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development

On Tue, Nov 08, 2005 at 04:26:38PM -0000, Martin J. Evans wrote:
> I may being really daft here but I can't see why changing
> ShowErrorStatement should change what happens here (unless
> it is consuming errors before the error handler is called).
>
> bash-2.05$ perl -MDBI -e 'print "$DBI::VERSION\n";'
> 1.48
> bash-2.05$ perl --version
> This is perl, v5.8.7 built for i686-linux
>
> Driver is MyODBC 3.51.12 but it reports
> bash-2.05$ perl -M'DBD::mysql' -e 'print "$DBD::mysql::VERSION\n";'
> 3.0002
>
> use strict;
> use warnings;
> use DBI;
> use Carp;
>
> my $dbh = DBI->connect("dbi:ODBC:xxx", "yyy", "zzz",
> {RaiseError => 1, PrintError => 1, ShowErrorStatement => 0,
> HandleError => \&error_trap});
> my $sth = $dbh->prepare("sselect * from bench_char");
> $sth->execute;
> sub error_trap
> {
> my ($msg, $h, $ret) = [at] _;
>
> print "Type=", $h->{Type}, "\n",
> "SQL=", $h->{Statement}, "\n",
> "Error=", $h->errstr, "\n";
> confess("confess");
> return 1;
> }
>
> shows:
>
> bash-2.05$ perl x.pl
> Type=st
> SQL=sselect * from bench_char
> Error=[unixODBC][MySQL][ODBC 3.51 Driver][mysqld-5.0.15-log]You have an
> error in your SQL syntax; check the manual that corresponds to your
> MySQL server version for the right syntax to use near
> 'sselect * from bench_char' at line 1
> (SQL-23000)(DBD: st_execute/SQLExecute err=-1)
> confess at x.pl line 21
> main::error_trap('DBD::ODBC::st execute failed:
> [unixODBC][MySQL][ODBC 3.51 Dri...',
> 'DBI::st=HASH(0x8248b04)', 'undef') called at x.pl line 12
>
> which is what I'd expect BUT simply changing ShowErrorStatement => 1 produces:
>
> bash-2.05$ perl x.pl
> Describe failed during DBI::st=HASH(0x8248af8)->FETCH(ParamValues,0)
> at x.pl line 12.
> Type=st
> SQL=sselect * from bench_char
> Error=[unixODBC][MySQL][ODBC 3.51 Driver][mysqld-5.0.15-log]
> Invalid cursor state (SQL-24000)(DBD: dbd_describe/SQLNumResultCols err=-1)
> confess at x.pl line 21
> main::error_trap('DBD::ODBC::st execute failed:
> [unixODBC][MySQL][ODBC 3.51 Dri...', 'DBI::st=HASH(0x8248b04)',
> 'undef') called at x.pl line 12
>
> It would appear setting ShowErrorStatement:
>
> 1. causes the code to run further before stopping
> 2. loses an error
>
> Any ideas?

The key is "Describe failed during DBI::st=HASH(0x8248af8)->FETCH(ParamValues,0)".
ShowErrorStatement is fetching the value of the ParamValues attribute
so it can add the parameter values, if any, to the error message.
But the FETCH of ParamValues is itself failing.

Tim.

> First off, I had no idea it existed until I started going through a dbi
> tutorial. The idea is you don't have to litter your code with "or
> die..." statements.

> Is it good practice to use this or is an explicit "or die..." better
> because you can "see" there is error trapping?

I think setting the RaiseError and PrintError attributes on your database
handle is the best way to do these things.

$dbh = DBI->connect($DSN, $user, $pass, { RaiseError => 1, PrintError
=> 0, AutoCommit =>0});

Hope this helps,
Stuart.

On Tue, Aug 14, 2007 at 11:17:26AM +1000, Stuart Cooper wrote:
> > First off, I had no idea it existed until I started going through a dbi
> > tutorial. The idea is you don't have to litter your code with "or
> > die..." statements.

I recommend that everyone who doesn't carefully read the release notes
(ie the Changes file extract I post with each release announcement)
should reread the DBI docs at least every couple of years.

> > Is it good practice to use this or is an explicit "or die..." better
> > because you can "see" there is error trapping?
>
> I think setting the RaiseError and PrintError attributes on your database
> handle is the best way to do these things.
>
> $dbh = DBI->connect($DSN, $user, $pass, { RaiseError => 1, PrintError => 0, ...

Yes, ShowErrorStatement just tweaks the behaviour of RaiseError and PrintError.

$dbh = DBI->connect($DSN, $user, $pass, { RaiseError => 1, PrintError => 0, ShowErrorStatement => 1, ...

Tim.

Tim Bunce wrote:
> On Tue, Aug 14, 2007 at 11:17:26AM +1000, Stuart Cooper wrote:
>>> First off, I had no idea it existed until I started going through a dbi
>>> tutorial. The idea is you don't have to litter your code with "or
>>> die..." statements.
>
> I recommend that everyone who doesn't carefully read the release notes
> (ie the Changes file extract I post with each release announcement)
> should reread the DBI docs at least every couple of years.
>
>>> Is it good practice to use this or is an explicit "or die..." better
>>> because you can "see" there is error trapping?
>> I think setting the RaiseError and PrintError attributes on your database
>> handle is the best way to do these things.
>>
>> $dbh = DBI->connect($DSN, $user, $pass, { RaiseError => 1, PrintError => 0, ...
>
> Yes, ShowErrorStatement just tweaks the behaviour of RaiseError and PrintError.
>
> $dbh = DBI->connect($DSN, $user, $pass, { RaiseError => 1, PrintError => 0, ShowErrorStatement => 1, ...
>
> Tim.

So I should still "or die..." even if I set ShowErrorStatement? I ask,
because if true, then I would like to let the author of the paper I am
reading know to make corrections if needed.

Robert

On Tue, Aug 14, 2007 at 09:16:15AM -0400, Robert Hicks wrote:
> Tim Bunce wrote:
> >On Tue, Aug 14, 2007 at 11:17:26AM +1000, Stuart Cooper wrote:
> >>>First off, I had no idea it existed until I started going through a dbi
> >>>tutorial. The idea is you don't have to litter your code with "or
> >>>die..." statements.
> >
> >I recommend that everyone who doesn't carefully read the release notes
> >(ie the Changes file extract I post with each release announcement)
> >should reread the DBI docs at least every couple of years.
> >
> >>>Is it good practice to use this or is an explicit "or die..." better
> >>>because you can "see" there is error trapping?
> >>I think setting the RaiseError and PrintError attributes on your database
> >>handle is the best way to do these things.
> >>
> >>$dbh = DBI->connect($DSN, $user, $pass, { RaiseError => 1, PrintError =>
> >>0, ...
> >
> >Yes, ShowErrorStatement just tweaks the behaviour of RaiseError and
> >PrintError.
> >
> > $dbh = DBI->connect($DSN, $user, $pass, { RaiseError => 1, PrintError =>
> > 0, ShowErrorStatement => 1, ...
>
> So I should still "or die..." even if I set ShowErrorStatement?

Setting ShowErrorStatement is unrelated to "or die..." so the question
seems flawed.

ShowErrorStatement just adds information to the message produced by
RaiseError and PrintError.

I recommend RaiseError. I recommend ShowErrorStatement.
I don't recommend "or die ...", generally.
If you're using RaiseError then "or die ..." is redundant.
If you're not using RaiseError then ShowErrorStatement is redundant
(unless PrintError is on).

Hopefully that helps.

Tim.

Tim Bunce wrote:
> On Tue, Aug 14, 2007 at 09:16:15AM -0400, Robert Hicks wrote:
>> Tim Bunce wrote:
>>> On Tue, Aug 14, 2007 at 11:17:26AM +1000, Stuart Cooper wrote:
>>>>> First off, I had no idea it existed until I started going through a dbi
>>>>> tutorial. The idea is you don't have to litter your code with "or
>>>>> die..." statements.
>>> I recommend that everyone who doesn't carefully read the release notes
>>> (ie the Changes file extract I post with each release announcement)
>>> should reread the DBI docs at least every couple of years.
>>>
>>>>> Is it good practice to use this or is an explicit "or die..." better
>>>>> because you can "see" there is error trapping?
>>>> I think setting the RaiseError and PrintError attributes on your database
>>>> handle is the best way to do these things.
>>>>
>>>> $dbh = DBI->connect($DSN, $user, $pass, { RaiseError => 1, PrintError =>
>>>> 0, ...
>>> Yes, ShowErrorStatement just tweaks the behaviour of RaiseError and
>>> PrintError.
>>>
>>> $dbh = DBI->connect($DSN, $user, $pass, { RaiseError => 1, PrintError =>
>>> 0, ShowErrorStatement => 1, ...
>> So I should still "or die..." even if I set ShowErrorStatement?
>
> Setting ShowErrorStatement is unrelated to "or die..." so the question
> seems flawed.
>
> ShowErrorStatement just adds information to the message produced by
> RaiseError and PrintError.
>
> I recommend RaiseError. I recommend ShowErrorStatement.
> I don't recommend "or die ...", generally.
> If you're using RaiseError then "or die ..." is redundant.
> If you're not using RaiseError then ShowErrorStatement is redundant
> (unless PrintError is on).
>
> Hopefully that helps.
>
> Tim.

As clear as clear can be... : )

Robert

Tim Bunce wrote:
> On Tue, Aug 14, 2007 at 09:16:15AM -0400, Robert Hicks wrote:
>> Tim Bunce wrote:
>>> On Tue, Aug 14, 2007 at 11:17:26AM +1000, Stuart Cooper wrote:
>>>>> First off, I had no idea it existed until I started going through a dbi
>>>>> tutorial. The idea is you don't have to litter your code with "or
>>>>> die..." statements.
>>> I recommend that everyone who doesn't carefully read the release notes
>>> (ie the Changes file extract I post with each release announcement)
>>> should reread the DBI docs at least every couple of years.
>>>
>>>>> Is it good practice to use this or is an explicit "or die..." better
>>>>> because you can "see" there is error trapping?
>>>> I think setting the RaiseError and PrintError attributes on your database
>>>> handle is the best way to do these things.
>>>>
>>>> $dbh = DBI->connect($DSN, $user, $pass, { RaiseError => 1, PrintError =>
>>>> 0, ...
>>> Yes, ShowErrorStatement just tweaks the behaviour of RaiseError and
>>> PrintError.
>>>
>>> $dbh = DBI->connect($DSN, $user, $pass, { RaiseError => 1, PrintError =>
>>> 0, ShowErrorStatement => 1, ...
>> So I should still "or die..." even if I set ShowErrorStatement?
>
> Setting ShowErrorStatement is unrelated to "or die..." so the question
> seems flawed.
>
> ShowErrorStatement just adds information to the message produced by
> RaiseError and PrintError.
>
> I recommend RaiseError. I recommend ShowErrorStatement.
> I don't recommend "or die ...", generally.
> If you're using RaiseError then "or die ..." is redundant.
> If you're not using RaiseError then ShowErrorStatement is redundant
> (unless PrintError is on).
>
> Hopefully that helps.
>
> Tim.

Maybe that can go in the wiki FAQ? : )

Robert

On Tue, Aug 14, 2007 at 07:01:23PM -0400, Robert Hicks wrote:
> Tim Bunce wrote:
> >
> >Setting ShowErrorStatement is unrelated to "or die..." so the question
> >seems flawed.
> >
> >ShowErrorStatement just adds information to the message produced by
> >RaiseError and PrintError.
> >
> >I recommend RaiseError. I recommend ShowErrorStatement.
> >I don't recommend "or die ...", generally.
> >If you're using RaiseError then "or die ..." is redundant.
> >If you're not using RaiseError then ShowErrorStatement is redundant
> >(unless PrintError is on).
> >
> >Hopefully that helps.
>
> Maybe that can go in the wiki FAQ? : )

Go ahead... http://dbi.tiddlyspot.com/ :)

Umm, guess I should actually announce that new FAQ sometime...

Tim.

Tim Bunce wrote:
> On Tue, Aug 14, 2007 at 07:01:23PM -0400, Robert Hicks wrote:
>> Tim Bunce wrote:
>>> Setting ShowErrorStatement is unrelated to "or die..." so the question
>>> seems flawed.
>>>
>>> ShowErrorStatement just adds information to the message produced by
>>> RaiseError and PrintError.
>>>
>>> I recommend RaiseError. I recommend ShowErrorStatement.
>>> I don't recommend "or die ...", generally.
>>> If you're using RaiseError then "or die ..." is redundant.
>>> If you're not using RaiseError then ShowErrorStatement is redundant
>>> (unless PrintError is on).
>>>
>>> Hopefully that helps.
>> Maybe that can go in the wiki FAQ? : )
>
> Go ahead... http://dbi.tiddlyspot.com/ :)
>
> Umm, guess I should actually announce that new FAQ sometime...
>
> Tim.

You should...and if you didn't recognize the name; I am the one that
helps you with it. ; )

Robert

On Wed, Aug 15, 2007 at 01:03:03PM -0400, Robert Hicks wrote:
> Tim Bunce wrote:
> >On Tue, Aug 14, 2007 at 07:01:23PM -0400, Robert Hicks wrote:
> >>Tim Bunce wrote:
> >>>Setting ShowErrorStatement is unrelated to "or die..." so the question
> >>>seems flawed.
> >>>
> >>>ShowErrorStatement just adds information to the message produced by
> >>>RaiseError and PrintError.
> >>>
> >>>I recommend RaiseError. I recommend ShowErrorStatement.
> >>>I don't recommend "or die ...", generally.
> >>>If you're using RaiseError then "or die ..." is redundant.
> >>>If you're not using RaiseError then ShowErrorStatement is redundant
> >>>(unless PrintError is on).
> >>>
> >>>Hopefully that helps.
> >>Maybe that can go in the wiki FAQ? : )
> >
> >Go ahead... http://dbi.tiddlyspot.com/ :)
> >
> >Umm, guess I should actually announce that new FAQ sometime...
> >
> >Tim.
>
> You should...and if you didn't recognize the name; I am the one that
> helps you with it. ; )

I did Bob. I just thought I'd use the post as an excuse to spread both
the url and the message that it's open for editing.

Thanks again for helping, and volunteering to be the editor.

Must get to work on an announcement...

Tim.