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: standard execution of stored proc
Date: Jun 17 1998 11:22PM

Curtis Johnson writes:
 > Regarding DBlib v. CTlib:
 > 
 > I am fairly familiar with the Dblib method of
 >          $dbh->dbcmd("declare \@err_msg varchar(20)") ;
 >          $dbh->dbcmd("exec ag_ins_hnp .....
 > 
 >         $dbh->dbcmd(", \@err_msg output");

(etc...)

This is the case where nsql() does not quite handle the situation
right, because you need to call dbretdata() to get the OUTPUT params
from the stored proc, and neither nsql() nor sql() do so.

The CTlib equivalent of sql() (ct_sql()) implicitly fetches *all* the
available results & rows, because they are all fetched via ct_fetch().

So the array reference returned by $dbh->ct_sql() with one (or
several) stored procs that return OUTPUT params will include any rows
output from any SELECT statements in the stored procs, any OUTPUT
params to the stored procs, and the return status of each stored
proc. Unfortunately at the moment this data is not separated in any
logical fashion.

But I would guess that something like nsql() for CTlib would return
data in more structured manner.

In general however, you get OUTPUT params in CTlib when ct_results()
returns a result type of CS_PARAM_RESULT, and then you call ct_fetch() 
to retrieve the actual values.

See the discussion on ct_result() in the Sybase OpenClient manual...

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