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 2:33PM

W. Phillip Moore writes:
 > >>>>> "Lee" == Lee Falkenhagen  writes:
 > 
 > Lee> Okay, so that works pretty well.  Why would you ever want to use
 > Lee> dbcmd, dbsqlexec, and dbresults if you can do the same thing with
 > Lee> nsql or sql?  It looks like even multi statement sql works with
 > Lee> the sql command.
 > 
 > IM!HO, you wouldn't.  I have put a fair amount of effort into making
 > nsql() as bullet proof as possible, simply because properly calling
 > and error checking the DBlib routines is not trivial.
 > nsql() makes it trivial, and for *most* SQL it will work fine (I'd say 
 > all, but there are surel some perverse exceptions...)

I mostly agree with Phillip, and I've written several modules that
live on top of Sybase::DBlib (or Sybase::CTlib) that handle most cases 
correctly, and return structured data (array of hash, hash of hash,
etc).

This works fine, except when calling multiple stored procedures in a
single batch, and you want to check the result status of each sproc in 
the perl code rather than the SQL, or correctly handling OUTPUT params 
to stored procs.

Another case where sql()/nsql() falls down is when you need to iterate 
over a very large table, as these routines store the entire result set 
in a perl array, which is impractical when you need to handle millions 
of rows...

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