sybperl-l Archive

From: Michael Peppler <mpeppler at MBAY dot NET>
Subject: Re: further syb_more_results problems in DBD::Sybase 0.08?
Date: Jun 4 1998 2:01PM

Ken Fasman writes:
 > Thanks for the help Michael, that does the trick.
 > 
 > Any chance of better documenting this behavior in the DBD::Sybase
 > docs?

Yeah - that will happen (somtime...)

 >  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. 

If it makes you feel any better it wasn't really obvious to me either.

But I think the general concept is that you should check fot $sth->err 
being set after *every* DBI call, so you would have the check inside
the loop *as well as* after the loop to catch any possible errors.

Michael

 > 
 > 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?
 > 
 > 

-- 
Michael Peppler         -||-  Data Migrations Inc.
mpeppler@datamig.com    -||-  http://www.mbay.net/~mpeppler
Int. Sybase User Group  -||-  http://www.isug.com