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