Michael Peppler
Sybase Consulting
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
Sybase on Linux FAQ
Sybperl FAQ
Michael Peppler's resume

sybperl-l Archive

Up    Prev    Next    

From: Ken Fasman <ken at genome dot wi dot mit dot edu>
Subject: Re: further syb_more_results problems in DBD::Sybase 0.08?
Date: Jun 4 1998 2:49AM

Thanks for the help Michael, that does the trick.

Any chance of better documenting this behavior in the DBD::Sybase docs?  Both 
they and the docs for DBI are pretty lean on the topic of error handling in 
general.  It certainly was not obvious to us exactly *where* to put this 
check in. 

Thanks again,

On Wed, 3 Jun 1998, Michael Peppler wrote:

> Ken Fasman writes:
>  > I realize now that my posting is missing some important data:
>  > 
>  > If you use the default values for PrintError and RaiseError on connecting 
>  > to the database, the messages all come back to the client regardless of the 
>  > presence of the SELECT in the nested procedure.
>  > 
>  > However, we would like to set them both false, and do our own handling of 
>  > $h->err and $h->errstr, particularly in a CGI environment where one doesn't 
>  > want uncontrolled messages going to STDOUT or STDERR.
>  > 
>  > Again, perhaps my sample script is just handling these errors improperly in 
>  > the absence of the default PrintError handling?
> I get the desired behaviour if change the do loop like this:
> do {
>     ++$i;
>     print "Result set $i\n";
>     print "------------\n";
> #    print ("Result error: ".$sth->errstr."\n") if ($sth->err);
>     while ( $hash = $sth->fetchrow_hashref() ) {
> #	print ("Result error: ".$sth->errstr."\n") if ($sth->err);
> 	foreach $key (keys %$hash) {
> 	    print "$key: $$hash{$key}\n";
> 	}
>     }
>     print ("Result error: ".$sth->errstr."\n") if ($sth->err);
> } while ($sth->{syb_more_results});     ##### Warning!  DBD::Sybase extenstion!
> ie moving the error printing out from the actuall fetch() loop.
> I'm not 100% sure why this behaves correctly and the other does not,
> except that I guess the $sth->err value gets reset on each fetch()
> call, and the error is actually flagged on the fetch() call that
> returns an empty array...
> Michael
>  > 
>  > Thanks,
>  > Ken
>  > 
>  > > Looks like I may have found another bug regarding handling of syb_more_results 
>  > > and error processing.  Enclosed is a simple DBI script and two stored procs, 
>  > > "Caller" and "Callee".  They are simulating a stored proc API which calls 
>  > > a common library of other stored procs.  If you pass a -1 to Caller, so that 
>  > > it in turn causes Callee to raise an error, Caller also raises one.  When 
>  > > the SELECT is present in Caller resulting in multiple result sets, the 
>  > > error messages are never returned to the DBI client.  If you comment out 
>  > > the SELECT in Caller, the DBI client behaves correctly.
>  > > 
>  > > Is this in fact a DBD::Sybase 0.08 bug, or am I processing the error flags 
>  > > improperly in the Perl script?