DBI->trace(3, "trace.txt");
[download]

  0 - Trace disabled.
  1 - Trace DBI method calls returning with results or errors.
  2 - Trace method entry with parameters and returning with results.
  3 - As above, adding some high-level information from the driver and
+ some internal information from the DBI.
  4 - As above, adding more detailed information from the driver. Also
+ includes DBI mutex information when using threaded Perl.
  5 - As above but with more and more obscure information.
[download]

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just go the the link and check out our stats.

PrintError (boolean, inherited)

This attribute can be used to force errors to generate warnings (using
+ warn) in addition to returning error codes in the normal way. When s
+et ``on'', any method which results in an error occuring will cause t
+he DBI to effectively do a warn("$class $method failed: $DBI::errstr"
+) where $class is the driver class and $method is the name of the met
+hod which failed. E.g., 
  DBD::Oracle::db prepare failed: ... error text here ...
By default, DBI->connect sets PrintError ``on''.

If desired, the warnings can be caught and processed using a $SIG{__WA
+RN__} handler or modules like CGI::Carp and CGI::ErrorWrap.
[download]

eval {
      $ref = $dbh_g->selectcol_arrayref($sql)
     };
[download]

eval("$ref = $dbh_g->selectcol_arrayref($sql)")
[download]

I think either version of eval is equivalent as far as error trapping is concerned.

Regardless, the latter version would fail, since $sql and $dbh_g would be interpolated as the string were parsed, prior to sending the resulting argument to eval. The result would be bad Perl syntax and execution would fail. You could just put it in single-quotes instead, which would work, but you're still incurring the compilation overhead at run-time instead of putting it into a block, which is compiled along with the rest of the script.

..Theo

How do I ensure errors don't go to stdout? I think this is my problem. Or how do I ask DBI not to complain at all?

Update:      $dbh->{PrintError} = 0; solves the problem, see below.

Personally, I'd be less that thrilled at the idea of surpressing error output -- it might actually help the user to know that something is wrong.

I've had some luck (it depends a little on what you want to do) with changing the 'execute or die' syntax to an 'execute or assign the error to a subroutine'.

Your error subroutine could then distinguish between errors as a result of access levels vs. error as a result of the database itself... and act accordingly.

Obviously, YMMV

Note: Code samples are for conceptual use only and generally are not meant to be cut/pasted into a production application. Always 'use strict', have a thorough understanding of the code you use, and check the return values of functions and handle errors according to your needs. - Fastolfe

right, I agree,
but the assignement of the query result to the variable happens, before that variable gets evaluated. And he is not looking for the result of the eval as he would do by saying :

      $ref = eval{$dbh_g->selectcol_arrayref($sql)};
[download]

??
Have a nice day
All decision is left to your taste

They are equivalent. Consider:

$a = $b = 0;

eval { $a = 3; };
$b = eval { 3; };

print "$a, $b\n";    # 3, 3
[download]

Eval operates in the same context as any other code. The return from eval is the return value of whatever that eval did. The only difference is that eval blocks can't die; errors are stored in $@ and execution of the eval block stops.