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 3 1998 3:37PM

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?

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?