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,
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
Michael Peppler -||- Data Migrations Inc.
email@example.com -||- http://www.mbay.net/~mpeppler
Int. Sybase User Group -||- http://www.isug.com