PEPPLER.ORG
Michael Peppler
Sybase Consulting
Menu
Home
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
Freeware
Sybperl
Sybase::Simple
DBD::Sybase
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
FAQs
Sybase on Linux FAQ
Sybperl FAQ
Personal
Michael Peppler's resume

sybperl-l Archive

Up    Prev    Next    

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

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