sybperl-l Archive

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,
Ken

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?